Vulnerability handling record

What this is#

Four working sheets and a standing-rules sheet, for the vulnerability-handling process the Cyber Resilience Act requires of a manufacturer. Annex I Part II asks for a bill of materials and a disclosure policy. It also asks for updates with advisory messages, and disclosure once a fix exists ¹.

How to use it#

1. Delete the twelve example rows before the first real entry.
2. Fill the SBOM index from the release pipeline, one row per product version. Point (1) asks for a commonly used, machine-readable format covering at the very least the top-level dependencies ².
3. Open a Disclosure log row for every report, and record its source. See the playbook, section 3.3.
4. Keep severity and actively exploited apart. They answer different questions, and the triage cell carries the reasoning. See section 3.4.
5. Name affected versions from the SBOM index, not from memory. Requirement DM-3 in IEC 62443-4-1:2018 expects every other affected version to be identified ³.
6. Add an Update log row per release, naming the versions superseded and the identifiers closed.
7. Open a Reporting clock row at awareness, including for events found not notifiable, with the reason in the event cell. See the playbook, section 3.7.
8. Compute the due dates from Became aware: early warning 24 hours later, the fuller notification 72 hours later ⁴.

What good looks like#

Six of the thirteen Disclosure log columns, from the workbook's rows.

ID	Severity	Actively exploited	Fix due	Update released	Closed
VUL-001	1. Critical	1. Yes	2026-09-25	2026-09-25 (UPD-001)	2026-10-07
VUL-002	2. High	1. Yes	2026-11-06	2026-11-06 (UPD-002); 2026-11-10 (UPD-003)	2026-11-18
VUL-003	3. Medium	2. No	2027-01-29	—	—

The third row is the instructive one: a flaw in a transitive dependency, not reachable here, carries no reporting duty and no advisory, and still needs an owner and a date.

Fields#

Field	Required	Meaning	Common mistake
Format, Generated on	yes	The SBOM format, and the date it was produced	A record older than the version shipping today
Last diff	yes	What changed since the previous version	An empty cell where nothing was compared
Severity, Actively exploited	yes	How bad it is, and whether exploitation is evidenced	Reading a high score as an Article 14 trigger
Triage decision	yes	Why this order, and whether the duty attaches	A status word where reasoning belongs
Became aware	yes to notify	When the initial assessment reached reasonable certainty	The moment the notification was drafted
Final report due	yes to notify	14 days after a measure is available, or one month after the 72-hour notification	Using one anchor for both event types

The two anchors differ by event type, and sit in one column ⁵.

Download#

• File: vulnerability-handling-record.xlsx (xlsx, 11 KB) — five sheets: Read first, SBOM index, Disclosure log, Update log, Reporting clock.
• Markdown variant: the same tables in plain markdown, at content/templates/assets/_vulnerability-handling-record.md.
• Licence: CC BY 4.0 — reuse and adapt with attribution to GRCIDE.
• Version: 1.0, 2026-09-05. No personal data, no organisation or tool names; the example rows are invented.

Related#

• Playbook: Vulnerability handling and the SBOM under the CRA
• Briefing: CRA obligations by product class, and the radar entry on reporting

References#

1. European Parliament and Council. Regulation (EU) 2024/2847 (Cyber Resilience Act). OJ L, 2024/2847, 20.11.2024. Annex I Part II and Article 14 read at https://publications.europa.eu/resource/celex/32024R2847 ⁶
2. IEC. IEC 62443-4-1:2018 — Security for industrial automation and control systems - Part 4-1: Secure product development lifecycle requirements. Clause 10.4 read in a licensed copy; https://webstore.iec.ch/en/publication/33615 ⁷

Standards and certification names are the property of their respective owners. GRCIDE is an independent publication and is not affiliated with, authorized, sponsored or endorsed by ISO, IEC, NIST or any other standards body.