Applies to: NIS2 entities organizing documentary programs for baseline audit readiness.
Requirement-to-document mapping is the control that prevents fragmentation in NIS2 documentation. In Aegister's method, each requirement point is explicitly linked to a primary document, supporting artifacts, responsible roles, and review frequency. This creates traceability from regulatory obligation to concrete evidence, essential for both internal governance and inspection readiness.
Key Takeaways
- Mapping must be done at requirement-point level, not just policy title.
- Each mapped requirement must specify a primary document and supporting evidence.
- Overlaps are natural, but ownership and precedence rules must be explicit.
- Appendix B and Appendix C items need dedicated matrix tags.
Scope of This Article
This article covers:
- A practical NIS2 requirement-to-document mapping method.
- How to structure mapping tables for audit and remediation use.
- How to handle overlaps, gaps, and governance-sensitive requirements.
This article does not cover:
- Client-identifying evidence or internal records.
- Full proprietary templates or internal worksheets.
Official Baseline References
| Source | Why it matters for mapping |
|---|---|
| Legislative Decree 138/2024 | Defines legal scope for governance, risk measures, and incident obligations. |
| ACN Determination on baseline obligations | Establishes measure/point structure and technical annexes for matrix derivation. |
| ACN Reading Guide | Clarifies evidence logic and Appendix B / Appendix C interpretation for documentary controls. |
| ACN NIS baseline page | Provides implementation context and baseline timeline. |
For important entities, the baseline logic covers 37 measures and 87 requirement points in first application (ACN Reading Guide).
Why Mapping Fails in Practice
- Policies exist, but requirement points are not explicitly assigned.
- Evidence is listed, but not linked to individual obligations.
- Multiple documents cover the same requirement with no ownership rule.
- Governance approval checkpoints are added too late.
Mapping Model (4 Levels)
| Level | Mapping object | Required field examples |
|---|---|---|
| L1 | Requirement point | Measure code, point code, category, regulatory anchor |
| L2 | Primary document | Document ID, owner, status, review frequency |
| L3 | Supporting evidence | Procedure/plan/register references, evidence maturity level |
| L4 | Governance controls | Approval tag, risk-linkage tag, dependency tag |
Recommended Mapping Table Structure
| Field | Mandatory | Why it matters |
|---|---|---|
Requirement code (e.g. ID.RA-05:p1) | Yes | Atomic traceability |
| Primary document | Yes | Single accountability point |
| Supporting evidence/documents | Yes | Implementation proof chain |
| Control owner | Yes | Execution responsibility |
| Review frequency | Yes | Lifecycle governance |
Status (draft, approved, needs_update) | Yes | Operational planning |
| Appendix B tag (if applicable) | Conditional | Risk-linkage control |
| Appendix C tag (if applicable) | Conditional | Approval-sensitive control |
Mapping Workflow
- Build inventory of applicable requirements from baseline framework.
- Assign a primary document for each requirement point.
- Add supporting evidence references for each point.
- Mark overlap dependencies and precedence rules.
- Tag Appendix B and Appendix C sensitive items.
- Validate ownership, review frequency, and document status.
- Freeze matrix version as audit baseline.
Managing Overlaps Without Losing Control
When a requirement is covered by multiple documents:
- Define one accountable primary document.
- Mark others as supporting or complementary.
- Record cross-reference direction explicitly.
- Verify consistency of definitions, roles, and escalation logic.
Gap Detection Rules from Mapping
A requirement should be flagged as a gap when at least one condition applies:
- No primary document assigned.
- Primary document exists, but no traceable evidence.
- Appendix B item without explicit risk linkage where expected.
- Appendix C item without governance approval path in documentary architecture.
- Missing owner or review frequency.
Deliverables from a Well-Built Matrix
- Master requirement-to-document matrix.
- Evidence dependency map.
- List of governance-sensitive controls (Appendix B/C tagged items).
- Remediation backlog ordered by criticality and dependency.
Quality Check Before Publishing
- Requirement codes complete and consistent.
- Every requirement has an accountable primary document.
- Supporting evidence traceable at least at locator level.
- Cross-references between documents consistent and non-contradictory.
- EN/IT structure aligned for bilingual compliance operations.
FAQ
Is mapping the same as writing policies?
No. Mapping is the governance/traceability layer that guides writing, review, and remediation.
Can we map before all documents are final?
Yes. Early mapping is recommended because it surfaces ownership gaps and dependencies before approval cycles.
What if a requirement spans multiple processes?
Define one accountable primary document and mark other references as supporting dependencies.
If there is interpretive ambiguity, which source prevails?
Official baseline sources prevail: ACN Determination, ACN Reading Guide.
Conclusion
Requirement-to-document mapping is the foundation of a defensible NIS2 documentary program. It creates explicit accountability, reduces overlap risk, and provides the structure needed to move from document production to evidence-backed compliance execution.
Related reading
- Compliance Documentation Audit for NIS2 Baseline Obligations: Method Overview
- NIS2 Evidence Matrix and Board-Approval Readiness: Practical Audit Method
- NIS2 Documentation Audit Checklist: Operational Method for Baseline Readiness
- Aegister NIS2 Compliance Service
- Aegister Virtual CISO Service