CRA vulnerability handling policy: free template for Confluence
Annex I, Part II of the Cyber Resilience Act lists eight vulnerability handling requirements, and they apply from 11 December 2027. This template turns them into a one-page policy your team can adopt in Confluence: who does what, how fast, and where the evidence lives.
Vulnerability handling policy: [Product or product family]
Owner: [Name, role] · Approved by: [Name, role] · Version and date: [1.0, date] · Next review: [date]
1. Scope
Products and versions covered: [list or link to the product register]. Support period for each version: [end month and year], at least five years unless the product is expected to be used for less (Art. 13(8)).
2. Components and SBOM
- Each released version has a software bill of materials in [CycloneDX / SPDX], covering at least top-level dependencies, generated by the build (Annex I, Part II, 1).
- SBOMs are kept with the technical documentation for at least ten years or the support period, whichever is longer.
3. Receiving reports
- Public contact for vulnerability reports: [security@… / web form]. Coordinated vulnerability disclosure policy: [link] (Annex I, Part II, 5 and 6).
- Every report is recorded within [one working day] in [Jira project], with the time it was received.
4. Assessing and fixing
- Triage by [role] within [time]: affected versions (SBOM search), severity, exploitation status.
- Fixes are made without delay; security updates are released separately from feature updates where technically feasible (Annex I, Part II, 2).
- Security testing and reviews: [frequency and method] (Annex I, Part II, 3).
5. Actively exploited vulnerabilities and severe incidents
- The moment of awareness is recorded with its evidence. [Role] decides whether the case is reportable and signs the decision.
- Early warning within 24 hours, notification within 72 hours, final report 14 days after a fix is available (one month after the notification for a severe incident), through the ENISA single reporting platform (Art. 14).
- Affected users are informed of the issue and the measures they can take (Art. 14(8)). Back-up for the decision-maker: [name].
6. Distributing updates and disclosing
- Updates are distributed securely, without delay and free of charge, with an advisory that tells users what to do (Annex I, Part II, 7 and 8).
- Once an update is available, fixed vulnerabilities are disclosed: description, affected products, impact, severity and how to remediate (Annex I, Part II, 4). Format: [advisory page / CSAF].
7. Records
| Record | Where | Kept for |
|---|---|---|
| Vulnerability cases and decisions | [Jira project] | [10 years] |
| Reports sent to the CSIRT and ENISA, and to users | [Jira / Confluence] | [10 years] |
| SBOMs per version | [location] | [10 years or support period] |
How to use it in Confluence
- Click Copy the template, open a new Confluence page and paste: headings, lists and tables stay as they are.
- Replace the parts in [brackets] and delete what does not apply to you.
- To reuse it, save it as a space template: Space settings › Templates › Create template, then paste.
What the template does not do for you
A policy is only as good as the records behind it. The CRA expects you to show, case by case, when you became aware, what you decided and what you sent. Keep those records next to the work: in Jira, on the vulnerability work item.
This page helps you plan and document; it is not legal advice. Check the official text and your authority’s guidance. Source: Regulation (EU) 2024/2847, Art. 13, Art. 14 and Annex I, Part II. Related: CRA SBOM requirements, CRA support period, Article 14 deadline calculator.