Appearance
Scope and applicability
This page explains how NIS2 applicability is established and maintained in Modulos without a dedicated NIS2 descoping questionnaire.
How applicability works in Modulos now
Applicability is currently handled in three ways:
- Base scope requirements establish whether NIS2 is relevant at all.
- Conditional requirements include an explicit Applicability section that says when the duty applies, when it can be treated as out of scope, and what evidence should support that conclusion.
- NIS2 Scope tags allow users to filter these conditional duties manually.
This means the current NIS2 model is manual but explicit. It does not auto-hide requirements. Instead, it makes the scoping logic auditable.
Core scope requirements
| Requirement | Topic | Directive reference |
|---|---|---|
ORF-333 | NIS2 scope and entity classification | Arts. 2, 3 |
ORF-334 | Entity listing data submission and update duty | Art. 3(4)-(5) |
ORF-335 | Sector-act equivalence and residual duty assessment | Art. 4 |
ORF-349 | Implementing-act applicability governance | Arts. 21(5), 23(11); Reg. 2024/2690 |
Conditional requirements that need a scoping decision
| Requirement | When it matters | NIS2 Scope tag |
|---|---|---|
ORF-335 | Sector-specific Union legal acts may provide equivalent obligations | Article 4 Equivalent Union Act |
ORF-349 | Entity type is covered by Implementing Regulation 2024/2690 | 2024/2690 Covered Entity |
ORF-355 | Article 26 territoriality / EU representative analysis is required | Article 26 Cross-Border Entity |
ORF-356 | Organization is one of the Article 27 registry entities | Article 27 Registry Entity |
ORF-357 | Organization acts as a TLD registry or domain-registration service provider | Article 28 Domain or TLD Entity |
ORF-358 | Organization participates in an Article 29 information-sharing arrangement | Article 29 Information-Sharing Participant |
ORF-359 | Organization maintains or uses an Article 30 voluntary-notification path | Article 30 Voluntary Notifier |
MRF-291 | AI service supports a 2024/2690 covered entity type | 2024/2690 Covered Entity |
MRF-292 | AI service supports the trust-service 24-hour derogation path | Trust Service 24-Hour Derogation |
ORF-353 also contains a trust-service special-case note, but it remains a broadly applicable reporting requirement and is therefore not treated as a filter-only overlay.
What the tags mean
The NIS2 Scope tags are manual filtering aids, not automatic descoping logic.
Use them to:
- quickly isolate the special-case duties that need a scoping decision
- review the applicability note in each tagged requirement
- document why the requirement is in scope or out of scope for the project
Do not assume that a requirement is automatically removed from the framework merely because it carries a scope tag.
What to evidence in practice
For defensible scope decisions, organizations typically maintain:
- sector and service qualification rationale
- size-threshold and classification record
- legal analysis for Article 4 equivalence scenarios
- Article 3 entity-listing records and update log
- implementing-regulation applicability memo, where relevant
- a short scoping rationale for each tagged requirement that is treated as out of scope
AI-service implications
Scope is organization-driven, but scope decisions still affect MFF-15.
- if
ORF-349is in scope, reviewMRF-291 - if the trust-service derogation applies, review
MRF-292 - when organization scope changes, re-check the affected app-level requirements and controls
Related pages
NIS2 overview
Framework structure and OFF-15/MFF-15 split
Cybersecurity measures
Governance and implementation requirements derived from Articles 20 and 21
Operationalizing in Modulos
End-to-end rollout sequence for organization and AI-service projects
Disclaimer
This page is for general informational purposes and does not constitute legal advice.