Article 4: Sector-specific Union legal acts

Article 4: sector-specific union legal acts requirement means you must determine whether an EU sector rule already imposes cybersecurity risk-management and incident notification duties that are at least equivalent to NIS 2, and then document which NIS 2 provisions do or do not apply to your entity. Your job is to prevent double-regulation gaps, not to “pick the easier” rule. (Directive (EU) 2022/2555, Article 4)

Key takeaways:

• Build and maintain an “obligation mapping” that compares NIS 2 to any sector-specific Union legal acts that apply to you. (Directive (EU) 2022/2555, Article 4)
• Where sector rules are equivalent, the corresponding NIS 2 provisions (including supervision and enforcement) do not apply; you still need proof of equivalence and scope. (Directive (EU) 2022/2555, Article 4)
• Operationalize this as a governance control: ownership, decision records, and exam-ready evidence for incident reporting and risk measures. (Directive (EU) 2022/2555, Article 4)

Article 4 is a scope-and-precedence control. It does not add a new security safeguard by itself; it forces you to answer a hard supervisory question fast: “Which rule governs us for cybersecurity measures and incident notification, NIS 2 or a sector-specific EU act?” If you cannot show your work, you will struggle in an exam even if your technical controls are strong.

For a CCO or GRC lead, the practical goal is to create a repeatable method to (1) identify relevant sector-specific Union legal acts, (2) assess whether their requirements are “at least equivalent in effect” to NIS 2 obligations, and (3) lock in an internal applicability determination with owners and review triggers. (Directive (EU) 2022/2555, Article 4)

This requirement becomes real during incidents. Your incident triage must route the event into the correct notification track with the correct timing triggers, content requirements, and recipients. The fastest path to compliance is an obligation register and a notification workflow that are designed to be audited: clear decisions, versioned mappings, and retained evidence.

Regulatory text

Operator meaning of the text: Article 4 says that if a sector-specific Union legal act already requires essential or important entities to adopt cybersecurity risk-management measures and/or notify significant incidents, and those sector requirements are at least equivalent in effect to NIS 2, then the relevant NIS 2 provisions (including supervision and enforcement in Chapter VII) do not apply to those entities for that covered scope. Where sector-specific Union legal acts do not cover all entities, NIS 2 applies to those not covered. (Directive (EU) 2022/2555, Article 4)

What you must do with this:
You must make an explicit, documented determination of:

1. whether you are subject to any sector-specific Union legal acts for cybersecurity measures or incident notification, and
2. whether those obligations are at least equivalent in effect to the corresponding NIS 2 obligations, and
3. which NIS 2 provisions are therefore disapplied (and which remain in force). (Directive (EU) 2022/2555, Article 4)

Plain-English interpretation (requirement-level)

Requirement: Maintain a current, defensible mapping that identifies which cybersecurity risk-management and incident notification obligations govern your entity: NIS 2, a sector-specific EU act, or both (if equivalence does not fully cover scope). (Directive (EU) 2022/2555, Article 4)

Practical implication: Supervisors will not accept “we follow the sector rule” as a control. They will ask: Which sector rule? Equivalent to which NIS 2 articles? For which legal entity, services, systems, and locations? Who approved this? When was it last reviewed? Your deliverable is an exam-ready applicability decision record with operational workflows aligned to it.

Who it applies to

Article 4 affects any organization that could be an essential entity or important entity under NIS 2 and that also operates in a sector with EU-level sector cybersecurity or incident notification rules. (Directive (EU) 2022/2555, Article 4)

Entity scope you should test

• Regulated entities with sector EU rules: If you operate in a sector that is governed by an EU act covering cybersecurity measures and incident notification, you must test equivalence against NIS 2 rather than assume NIS 2 applies in full. (Directive (EU) 2022/2555, Article 4)
• Multi-entity groups: Different subsidiaries may be covered by different sector acts, and equivalence may differ by activity. Treat this as a legal-entity-by-legal-entity analysis, not a group-wide statement. (Directive (EU) 2022/2555, Article 4)
• Cross-border operations: You still need a consistent internal operating model. Article 4 is about which Union-level regime governs a topic; operationally you must still align to national transposition and supervisory expectations where you operate. (Directive (EU) 2022/2555)

Operational contexts where Article 4 shows up

• Incident response (triage and reporting)
• Cyber risk-management program scope (policies, controls, governance, oversight)
• Audit/exam readiness and supervisory engagement
• Third-party dependency management (because sector rules and NIS 2 both tend to test supply chain exposure through evidence, not statements of intent) (Directive (EU) 2022/2555)

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

Step 1: Build a “sector-acts applicability inventory”

Create an inventory that answers, for each legal entity and business line:

• What sector-specific Union legal acts apply (if any)?
• Do they impose cybersecurity risk-management measures?
• Do they impose significant incident notification requirements?
• What is the scope boundary (activities, systems, services, geography, regulated perimeter)? (Directive (EU) 2022/2555, Article 4)

Output artifact: Sector-acts applicability inventory (owned by Compliance/Legal with CISO input).

Step 2: Create an “equivalence mapping” against NIS 2 obligations

For each applicable sector act, map it to the NIS 2 obligations you would otherwise implement (risk-management measures and incident notification are the minimum focus from the excerpt). (Directive (EU) 2022/2555, Article 4)

Use a simple decision table:

NIS 2 obligation area	Sector act requirement exists?	Equivalent in effect?	Decision	Rationale / notes	Owner
Cyber risk-management measures	Yes/No	Yes/No/Partial	NIS 2 applies / disapplied / hybrid	cite internal analysis	CISO/CCO
Significant incident notification	Yes/No	Yes/No/Partial	NIS 2 applies / disapplied / hybrid	cite internal analysis	IR Lead/Legal

Equivalence standard: Article 4 uses “at least equivalent in effect.” Treat this as an outcome-based test: does the sector rule drive materially comparable governance, control expectations, and notification obligations for your risk profile and services? Document your reasoning. (Directive (EU) 2022/2555, Article 4)

Daydream tip (earned mention): Teams lose time debating equivalence in email. In Daydream, create a single obligation register entry per sector act, attach the mapping, assign owners, and track approval and review triggers as evidence.

Step 3: Produce a formal applicability determination (with sign-off)

Write a short memo (or register entry with approvals) that states:

• Covered entities and activities
• Which NIS 2 provisions are disapplied due to equivalence, and which still apply
• The operational procedures that implement the decision (incident workflow, risk program controls)
• Review triggers (material regulatory change, acquisition, new product, new geography, major incident) (Directive (EU) 2022/2555, Article 4)

Sign-off: Compliance/Legal + CISO + accountable executive for the in-scope entity.

Step 4: Operationalize incident triage and notification routing

Implement an incident decision tree that answers within the first hours of triage:

• Is the impacted service/system in the sector-regulated perimeter?
• Which notification regime is primary for this incident (sector act vs NIS 2)?
• If “hybrid,” which notifications must be made under each regime?
• Who drafts, approves, and sends notifications?
• What evidence must be preserved? (Directive (EU) 2022/2555, Article 4)

Control expectation: Codified escalation paths, tested in tabletop exercises, and tied to your obligation register so responders do not guess under pressure.

Step 5: Align cybersecurity risk-management controls to the governing regime(s)

Even when NIS 2 is disapplied for certain provisions, you still need a coherent control system. Do the following:

• Map your control framework (ISO 27001 / NIST CSF / CIS Controls) to the governing obligations
• Set control owners and testing cadence in your GRC system
• Ensure third-party dependencies are in scope for risk assessment, remediation tracking, and assurance (because supply chain evidence is commonly requested during supervision) (Directive (EU) 2022/2555)

Step 6: Establish ongoing monitoring and change management

Article 4 is not a one-time analysis. Add to your compliance change management:

• Regulatory watch for updates to sector acts and NIS 2 transposition impacts
• M&A / new service gating question: “Does this change our sector-act applicability or equivalence mapping?”
• Periodic re-approval of the applicability determination (tie it to your annual compliance plan)

Required evidence and artifacts to retain

Keep these in a single, indexed repository with version history:

1. NIS 2 obligation register / applicability register with jurisdictional applicability notes, owners, and milestones (practical best practice aligned to Article 4’s scope logic). (Directive (EU) 2022/2555, Article 4)
2. Sector-acts applicability inventory (legal entities, activities, systems). (Directive (EU) 2022/2555, Article 4)
3. Equivalence mapping workbook showing the “at least equivalent in effect” analysis and conclusions. (Directive (EU) 2022/2555, Article 4)
4. Applicability determination memo with approvals and effective date. (Directive (EU) 2022/2555, Article 4)
5. Incident notification runbooks: triage criteria, decision tree, draft templates, approval workflow, evidence checklist. (Directive (EU) 2022/2555, Article 4)
6. Incident simulation records: tabletop agendas, attendance, lessons learned, follow-up actions. (Directive (EU) 2022/2555)
7. Third-party dependency artifacts: critical third-party list, risk assessments, remediation tracking, and assurance results tied to services in scope. (Directive (EU) 2022/2555)

Common exam/audit questions and hangups

Expect these questions, and pre-answer them in your artifacts:

• “Which sector-specific Union legal act do you rely on for disapplication of NIS 2 provisions?” (Directive (EU) 2022/2555, Article 4)
• “Show me the equivalence analysis. Who performed it, and what criteria did you use?” (Directive (EU) 2022/2555, Article 4)
• “Which parts of NIS 2 still apply to you, and how do you ensure you didn’t miss residual obligations?” (Directive (EU) 2022/2555, Article 4)
• “During the last incident, how did you decide which authority to notify, and where is the evidence?” (Directive (EU) 2022/2555, Article 4)
• “How do you ensure responders follow the right notification path outside business hours?” (Directive (EU) 2022/2555, Article 4)
• “How are critical third parties reflected in your risk-management measures and incident response dependencies?” (Directive (EU) 2022/2555)

Frequent implementation mistakes (and how to avoid them)

1. Assuming a sector rule automatically overrides NIS 2.
   Fix: Require a written “equivalent in effect” mapping and sign-off for each obligation area. (Directive (EU) 2022/2555, Article 4)

2. Doing the analysis at group level and missing entity-by-entity differences.
   Fix: Inventory by legal entity, regulated activity, and system boundary; keep a clear scope statement. (Directive (EU) 2022/2555, Article 4)

3. Leaving incident notification routing to ad hoc legal judgment during an incident.
   Fix: Build a runbook and decision tree tied to the obligation register; pre-assign drafting and approval roles. (Directive (EU) 2022/2555, Article 4)

4. Treating third-party dependencies as procurement-only.
   Fix: Tie critical third parties to in-scope services, risk assessments, and incident playbooks (contact paths, outage/compromise signals, evidence retention). (Directive (EU) 2022/2555)

5. No change control for equivalence determinations.
   Fix: Put the determination under document control with triggers for re-review and re-approval. (Directive (EU) 2022/2555, Article 4)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so do not plan around a specific precedent. Your practical risk is supervisory friction: if you cannot prove your equivalence determination and show operational readiness for incident notification, you can face escalations, remediation demands, and credibility loss with regulators based on a governance gap rather than a technical failure. (Directive (EU) 2022/2555, Article 4)

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

You asked for speed. Use this as an operator’s sequence; adjust to your organization’s change control.

First 30 days (establish the decision and the paper trail)

• Stand up the obligation register entry for article 4: sector-specific union legal acts requirement and assign owners (Compliance/Legal, CISO, IR lead). (Directive (EU) 2022/2555, Article 4)
• Complete the sector-acts applicability inventory for each in-scope legal entity and service. (Directive (EU) 2022/2555, Article 4)
• Draft equivalence mapping for the two areas in the excerpt: risk-management measures and significant incident notification. (Directive (EU) 2022/2555, Article 4)
• Publish a first-version applicability determination memo with documented assumptions and interim controls. (Directive (EU) 2022/2555, Article 4)

Days 31–60 (make it operational)

• Convert the mapping into incident routing logic: triage checklist, decision tree, call tree, and notification drafting workflow. (Directive (EU) 2022/2555, Article 4)
• Run an incident notification tabletop using a scenario that crosses perimeters (regulated service plus shared infrastructure). Capture lessons learned and update runbooks. (Directive (EU) 2022/2555)
• Map your control framework to the governing obligations and confirm control ownership and testing evidence. (Directive (EU) 2022/2555, Article 4)

Days 61–90 (harden for supervision)

• Finalize equivalence rationale and get formal sign-off; store approvals and version history. (Directive (EU) 2022/2555, Article 4)
• Validate third-party dependency coverage for in-scope services (critical providers, contractual notification hooks, assurance evidence). (Directive (EU) 2022/2555)
• Build an exam packet: applicability memo, mappings, runbooks, tabletop records, and a crosswalk to your GRC control library.

Frequently Asked Questions

Does Article 4 let us ignore NIS 2 if we’re already regulated in a sector?

Only for the relevant provisions, and only where the sector-specific Union legal act requirements are at least equivalent in effect to NIS 2 obligations. You must document that equivalence and the exact scope where NIS 2 is disapplied. (Directive (EU) 2022/2555, Article 4)

What does “at least equivalent in effect” mean operationally?

Treat it as an outcomes and coverage test: does the sector act impose risk-management measures and incident notification duties that achieve comparable supervisory objectives for your in-scope services? Write down the comparison, gaps, and your final decision. (Directive (EU) 2022/2555, Article 4)

Who should own the Article 4 determination?

Compliance/Legal should own the legal applicability and recordkeeping, with the CISO owning the control mapping and the incident response lead owning notification workflows. The accountable business executive should approve the final determination for their entity. (Directive (EU) 2022/2555, Article 4)

We operate multiple services; some are sector-regulated and some are not. What do we do?

Build a perimeter map by service and legal entity, then apply a “hybrid” model: sector rule where equivalent and in scope, NIS 2 where not covered. Your incident triage must identify which perimeter is impacted. (Directive (EU) 2022/2555, Article 4)

What evidence will auditors ask for first?

The equivalence mapping and the signed applicability determination, followed by incident notification runbooks and proof that staff can execute them under pressure (tabletop records, role assignments, and retained incident artifacts). (Directive (EU) 2022/2555, Article 4)

How does this interact with third-party risk management?

Your mapping must account for how third parties affect your ability to meet risk-management measures and incident notification duties (detection, escalation, evidence). Keep a list of critical third parties tied to in-scope services and test those dependencies in exercises. (Directive (EU) 2022/2555)