Security Incident Notification Policy Template
An internal security incident notification policy for manufacturers, covering escalation procedures, Article 14 regulatory notification, and user communication. Designed to sit alongside your CVD policy as an internal-facing document.
Purpose and Trigger Conditions
Article 14(1)This policy governs how [COMPANY NAME] responds to and notifies relevant parties of security incidents affecting our products.
This policy is triggered when [COMPANY NAME] becomes aware of:
- A vulnerability in our product that is being actively exploited (Article 14 trigger)
- A severe security incident affecting product integrity, confidentiality, or availability
- A data breach involving personal data of EU residents (also triggers GDPR Article 33/34)
This policy does not replace the CVD Policy (for inbound researcher reports) but governs our internal incident response and outbound notification obligations.
Clearly separating your inbound CVD policy (for researchers) from your outbound incident notification policy (for regulators and users) prevents confusion. Both documents are required under CRA.
Incident Classification
Article 14(1)Severity Level 1 — Critical (Article 14 Mandatory) Triggered by: Actively exploited vulnerability OR severe incident with potential significant impact Notification required: ENISA within 24 hours, Full notification within 72 hours
Severity Level 2 — High Triggered by: Confirmed vulnerability with high CVSS score (≥7.0), no known exploitation Notification: Internal tracking, accelerated remediation, prepare advisory
Severity Level 3 — Medium Triggered by: Confirmed vulnerability, CVSS 4.0–6.9, limited scope Notification: Internal tracking, standard remediation timeline
Severity Level 4 — Low Triggered by: Minor vulnerability, CVSS <4.0, negligible impact Notification: Internal tracking, normal development cycle
Tying severity levels to Article 14 obligations makes the classification decision clear for first responders. Your team should not need to re-read the CRA to know when to notify ENISA.
Internal Escalation Process
Article 14(2)Step 1 — Detection and Triage (0–2 hours)
- Incident detected via: [CVD portal / monitoring system / customer report / internal discovery]
- Assign initial severity classification
- Notify: [SECURITY LEAD NAME / ROLE]
- Open incident ticket: [INCIDENT TRACKING SYSTEM]
- Reference: [INTERNAL-INC-YYYY-XXXX]
Step 2 — Escalation for Level 1 (2–4 hours)
- Notify: [CISO / CTO NAME]
- Notify: [LEGAL COUNSEL NAME] (for regulatory notification assessment)
- Assess Article 14 notification trigger
- Begin drafting early warning notification
Step 3 — 24-hour Early Warning (if Level 1)
- Submit early warning to ENISA / [NATIONAL CSIRT]
- Log submission with timestamp and reference number
- Initiate 72-hour full notification countdown
Name specific roles rather than generic titles where possible. Escalation procedures fail when people are unsure who to call. The 24-hour window is tight — pre-assigned responsibility is essential.
Regulatory Notification Procedure
Article 14(2), Article 14(3)Article 14 Notification (Level 1 incidents only)
24-hour Early Warning (submitted to: [ENISA SRP URL / NATIONAL CSIRT])
- Product affected, brief description, evidence of exploitation
- Template: See Article 14 Notification Template
- Submitted by: [DESIGNATED ROLE]
72-hour Full Notification
- Confirmed CVSS score and vector
- Root cause (preliminary)
- Remediation timeline
- User notification plan
- Submitted by: [DESIGNATED ROLE]
14-day Final Report
- Confirmed root cause analysis
- Completed remediation actions
- User notification actions taken
- Lessons learned
- Submitted by: [DESIGNATED ROLE]
All submissions must be retained for [5] years as part of our CRA compliance records.
Assign specific named roles (or job titles if roles rotate) to each submission. Regulators will ask who submitted each notification — vague ownership leads to missed deadlines.
User and Customer Notification
Article 14, GDPR Article 34When to notify users:
- Immediately when a patch or workaround is available
- For Level 1 incidents, consider proactive notification even before a patch if risk to users is significant
Notification channels (use all applicable):
- [ ] Product firmware update mechanism (OTA notification)
- [ ] Email to registered users: [EMAIL TEMPLATE — see [TEMPLATE URL]]
- [ ] Website security advisory: [ADVISORY URL]
- [ ] Support portal announcement
- [ ] Direct contact for enterprise customers: [ACCOUNT MANAGER PROCESS]
Content of user notification:
- What happened (non-technical summary)
- Which products and versions are affected
- What users should do (update, apply workaround, change credentials)
- How to get help
- Contact: [SUPPORT URL / EMAIL]
User notification is separate from regulatory notification. Under GDPR, if personal data is involved, notification to data subjects may also be required (Article 34). Coordinate with your DPO.
Post-Incident Review
Article 13(1), Annex IWithin [30] days of incident closure, [COMPANY NAME] will conduct a post-incident review to:
- Confirm root cause analysis
- Assess whether vulnerability also exists in other products
- Review whether detection could have occurred earlier
- Update threat model and security testing procedures
- Document lessons learned
- Verify all regulatory notifications are complete and filed
Post-incident review to be completed by: [SECURITY LEAD / CISO] Review documented in: [INCIDENT MANAGEMENT SYSTEM] Retained for: [5] years
Post-incident reviews are evidence of your Article 13(1) obligation to have an ongoing security lifecycle. Regulators look for this documentation in audits to show your CVD programme improves over time.
Use this template automatically in CVD Portal
CVD Portal generates your CVD policy, tracks acknowledgments, and creates an audit trail — free, forever.
Set up your free portal