Under the ACN baseline framework, the incident management plan is explicitly listed among documents requiring approval by management and directive bodies (Appendix C, RS.MA-01 point 2).
The incident notification regime is already active from January 2026. Operationally, organizations should run a documented model that links incident handling phases with CSIRT notification duties and internal governance escalation.
Key takeaways
- The incident management plan is both a governance document and an operational execution standard.
- RS.MA-01 requires documented phases, notification procedures, roles, and incident reporting structure.
- CSIRT notification flow should be integrated with investigation and decision governance, not treated as a separate compliance task.
- Time discipline starts from incident evidence, so detection and triage quality directly affect legal compliance.
Regulatory framing for incident process and CSIRT notification
The ACN incident guideline describes incident management as an end-to-end process including preparation, detection, response, recovery, and improvement. It also clarifies that, for significant incidents, notification obligations to CSIRT Italia are part of the same governance and operational chain.
The baseline model states that notification timing runs from incident evidence. In this context, pre-notification is expected within 24 hours and notification within 72 hours from evidence, with subsequent updates as required by the framework.
What an approvable RS.MA-01 plan should include
| Section | Why it matters for RS.MA-01 execution |
|---|---|
| Incident lifecycle phases and procedures | Ensures repeatable handling from detection to closure |
| Notification workflow to CSIRT Italia | Connects legal obligations to operational triggers |
| Roles and responsibilities matrix | Clarifies accountability for triage, escalation, and reporting |
| Contact model (including CSIRT referent) | Reduces delay risk in mandatory communications |
| Evidence and incident documentation model | Supports auditability and post-incident learning |
| Integration with recovery and crisis plans | Aligns technical and governance responses under pressure |
Practical structure from the Aegister template approach
1. Objective, scope, and references
Define incident types in scope, service perimeter, and legal/baseline references.
2. Incident process model by phase
Document preparation, identification, response, recovery, and improvement with clear handoffs.
3. Notification decision and timing logic
Define evidence threshold, significance criteria, and escalation points for CSIRT communication.
4. Roles, contacts, and CSIRT referent governance
Assign incident manager, technical leads, legal/communications interfaces, and designated CSIRT referent.
5. Reporting and documentation standards
Standardize incident records, timeline tracking, intermediate updates, and closure reporting.
6. Recovery and post-incident improvement loop
Link incident closure to corrective actions, risk updates, and control hardening.
Common quality gaps to avoid
- Incident response described, but notification workflow not operationalized.
- No explicit trigger for when “incident evidence” is considered established.
- Roles missing for CSIRT communication and legal coordination.
- Weak evidence model that cannot support timeline reconstruction.
- Lessons learned not translated into control or process improvements.
20-day hardening checklist
| Week | Priority actions |
|---|---|
| Week 1 | Validate incident taxonomy, significance criteria, and role matrix |
| Week 2 | Finalize CSIRT notification workflow and reporting templates |
| Week 3 | Run simulation for evidence-to-notification timeline and close priority gaps |
FAQ
Is the incident management plan subject to formal management approval?
Yes. Appendix C includes the incident management plan among documents requiring approval by management and directive bodies (RS.MA-01 point 2).
When does the notification clock start for significant incidents?
The notification timeline starts from incident evidence, meaning the moment objective elements show that a qualifying incident has occurred.
Is there a practical minimum output expected from this plan?
A working operational model that links incident handling phases, CSIRT notification duties, accountable roles, and auditable evidence.
Conclusion and next steps
For NIS2, incident management and CSIRT notification must run as one integrated process. Organizations that formalize evidence thresholds, timing governance, and role accountability are better positioned to handle live notification obligations and broader October 2026 baseline expectations.
Related reading
- NIS2 mandatory documents master guide: what must be approved by the board and what to prepare now
- NIS2 incident-notification obligations are live: operating model after the 9-month deadline
- NIS2 Point of Contact and CSIRT Contact Role: Accountability and Operating Duties
- Aegister NIS2 Compliance Service
