What it is for
This template describes a vulnerability handling workflow for a manufacturer of products with digital elements, from the receipt of a report to disclosure and documentation. Each step cites the provisions it is aligned with. Roles, tools and evidence are left blank: fill them in for your organisation.
The reporting deadlines are reproduced as they appear in Article 14. The template adds no deadline of its own.
How to use it
- Read Part II of Annex I and Articles 13(6) to (9), 14, 15 and 16.
- For each step, write down the responsible role, the tool or channel and the evidence kept.
- Keep the two reporting tracks (actively exploited vulnerability; severe incident) visible to everyone on call: their clocks start when the manufacturer becomes aware.
- Test the workflow with a tabletop exercise and record the result.
- Review the template when implementing acts on notification formats and procedures are adopted (Article 14(10)).
1. Intake
- 1.1 Receive reports through the published contact address and the single point of contact, in line with the coordinated vulnerability disclosure policy. — Annex I, Part II, point 5, Annex I, Part II, point 6, Article 13(17)
- 1.2 Acknowledge and register the report with an identifier and the date and time of receipt. — Article 13(7)
Good practice (recommendation, not a legal requirement)
Logging the time of receipt and the time when the organisation became aware of exploitation is not required as such, but it makes the Article 14 deadlines traceable.
2. Triage and identification
- 2.1 Identify the affected products, versions and components, using the software bill of materials. — Annex I, Part II, point 1
- 2.2 If the vulnerability is in an integrated third-party component, including an open-source component, report it to the person or entity manufacturing or maintaining it, and share your fix where you developed one. — Article 13(6)
- 2.3 Assess whether the vulnerability is actively exploited. — Article 3, point (42)
- 2.4 For incidents, assess whether the incident is severe. — Article 3, point (44), Article 14(5)
What the text requires
An actively exploited vulnerability is a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner Article 3, point (42)
. A manufacturer shall notify any actively exploited vulnerability it becomes aware of simultaneously to the CSIRT designated as coordinator and to ENISA, via the single reporting platform (Article 14(1), Article 14(7)).
3. Reporting track — actively exploited vulnerability
| Step | What the text requires | Deadline in the text | Provision |
|---|---|---|---|
| 3.1 | Early warning notification, indicating where applicable the Member States where the product has been made available | Without undue delay and in any event within 24 hours of becoming aware | Article 14(2), point (a) |
| 3.2 | Vulnerability notification (unless the information was already provided) | Without undue delay and in any event within 72 hours of becoming aware | Article 14(2), point (b) |
| 3.3 | Final report (unless the information was already provided) | No later than 14 days after a corrective or mitigating measure is available | Article 14(2), point (c) |
| 3.4 | Intermediate report, if requested by the CSIRT designated as coordinator | On request | Article 14(6) |
4. Reporting track — severe incident
| Step | What the text requires | Deadline in the text | Provision |
|---|---|---|---|
| 4.1 | Early warning notification, including at least whether the incident is suspected of being caused by unlawful or malicious acts | Without undue delay and in any event within 24 hours of becoming aware | Article 14(4), point (a) |
| 4.2 | Incident notification (unless the information was already provided) | Without undue delay and in any event within 72 hours of becoming aware | Article 14(4), point (b) |
| 4.3 | Final report (unless the information was already provided) | Within one month after the submission of the incident notification | Article 14(4), point (c) |
Uncertain / awaiting guidance
The Commission may specify the format and procedures of the notifications by implementing acts (Article 14(10)), and the single reporting platform is established by ENISA (Article 16). Check the procedures and templates actually in force before relying on this template.
5. Remediation
- 5.1 Address and remediate the vulnerability without delay, including by providing a security update; where technically feasible, provide security updates separately from functionality updates. — Annex I, Part II, point 2
- 5.2 Test and review the fix and the security of the product. — Annex I, Part II, point 3
6. Distribution and user information
- 6.1 Distribute the update through a secure mechanism, automatically where applicable for security updates. — Annex I, Part II, point 7
- 6.2 Disseminate the security update without delay and, unless otherwise agreed with a business user for a tailor-made product, free of charge, with advisory messages. — Annex I, Part II, point 8
- 6.3 Inform impacted users, and where appropriate all users, of an actively exploited vulnerability or severe incident and of the mitigation measures they can take. — Article 14(8)
7. Disclosure
- 7.1 Once a security update is available, share and publicly disclose information about the fixed vulnerability; in duly justified cases, publication may be delayed until users have had the possibility to apply the patch. — Annex I, Part II, point 4
8. Documentation and follow-up
- 8.1 Document the vulnerability and the actions taken, and update the cybersecurity risk assessment where applicable. — Article 13(7), Article 13(3)
- 8.2 Keep each security update made available during the support period available for at least 10 years after issue or for the remainder of the support period, whichever is longer. — Article 13(9)
- 8.3 Recommendation: hold a short review after each case and adjust the workflow, contacts and templates.
- 8.4 Optional: voluntary notification of other vulnerabilities, cyber threats, incidents or near misses. — Article 15(1), Article 15(2)
Fictional example — A weekend report at Acme Routers
Acme Routers, an invented manufacturer, receives a report on a Saturday morning with logs showing a vulnerability being exploited on customer devices. The on-call engineer logs the time of awareness, the product owner confirms the evidence, and the early warning is prepared for submission within 24 hours via the single reporting platform. The 72-hour vulnerability notification follows once more information is available, and the final report is planned for no later than 14 days after the security update is published. Names, timings and facts are invented for illustration.
Downloadable version
The Excel workbook and the Word document contain the same 23 steps, with the provisions and a note for each, and empty columns for the owner (role), the tool or channel and the evidence kept.