The vulnerability management plan is a mandatory Appendix C document and requires governing/management approval under ID.RA-08 point 4. It should define how vulnerabilities are identified, prioritized, remediated, and tracked with clear accountability and measurable timelines.
Key takeaways
- Vulnerability planning is an approval-required governance deliverable, not only a SOC or IT-ops artifact.
- The plan must connect discovery, risk rating, remediation, and exception handling.
- Time-to-remediate targets should reflect risk criticality and business impact.
- A template-driven plan improves consistency across assets, suppliers, and technical teams.
What an approvable ID.RA-08 plan must show
| Objective | Minimum output | Evidence |
|---|---|---|
| Discovery coverage | Defined vulnerability sources and scope | Scan source inventory and coverage map |
| Prioritization logic | Severity + business context model | Risk-rating matrix |
| Remediation governance | Owner, target date, closure criteria | Remediation tracker |
| Exception control | Formal postponement/acceptance process | Exception register with approvals |
Practical vulnerability-plan structure
1. Purpose, scope, and references
Define covered assets, systems, software layers, and external dependencies.
2. Detection and intake model
Specify inputs (scanners, advisories, vendor notices, internal findings) and triage flow.
3. Prioritization and SLA matrix
Define risk classes and remediation target windows.
4. Remediation workflow
Describe assignment, implementation, validation, and closure steps.
5. Exceptions and compensating controls
Document how postponements are justified and which interim controls apply.
6. Reporting and governance oversight
Define KPI set (for example: open criticals, SLA breaches, aging backlog) and review cadence.
7. Periodic reassessment cycle
Set recurring review for model tuning and lessons learned.
Frequent plan failures
- Scanning exists but no decision model for prioritization.
- Critical vulnerabilities open without owner and due date.
- Exceptions granted informally without compensating controls.
- Supplier-facing vulnerabilities excluded from governance view.
- Closure marked without technical validation evidence.
20-day hardening checklist
- Consolidate vulnerability sources into one intake model.
- Define severity-to-deadline matrix aligned with business criticality.
- Assign accountable owners per asset domain.
- Introduce formal exception workflow and approval log.
- Define closure evidence standards and verification steps.
- Submit the plan for governing-body approval and periodic reporting.
FAQ
Is the vulnerability management plan a mandatory approval document?
Yes. Appendix C lists it with reference ID.RA-08 point 4.
Can patch management procedure replace the plan?
No. Procedures support execution; the plan defines governance, prioritization, accountability, and oversight.
Should supplier vulnerabilities be included?
Yes, where suppliers impact the security of systems and network services in scope.
Conclusion and next steps
A robust ID.RA-08 plan turns vulnerability handling into a governed risk-reduction process. The immediate priority is to enforce owner/date/closure discipline and make exception decisions auditable before they become backlog debt.
Related reading
- NIS2 mandatory documents master guide: what must be approved by the board and what to prepare now
- NIS2 Detection Controls (DE): Event Monitoring and Adversarial Signal Handling
- NIS2 Protection Controls (PR): Technical and Organizational Measures in Execution
- Aegister NIS2 Compliance Service
