The checklist should follow the vulnerability lifecycle from intake through closure. Product context matters: the team needs to know which products and versions are affected, whether the issue comes from an integrated component, what remediation is available, whether users need action and whether Article 14 reporting conditions may be met. Keep evidence of decisions, timelines and releases rather than only a ticket status.
Maintain a Monitored Vulnerability Intake Channel
The manufacturer needs an operational way for users, researchers, suppliers and internal teams to report potential vulnerabilities. The readiness checklist should confirm that the channel is monitored, routed to the right product-security function and connected to a record that preserves receipt time and reporter information where appropriate.
Validate the Vulnerability and Identify Affected Products
A vulnerability record should distinguish an unverified report from a confirmed product issue. Once confirmed, identify affected products, models, software or firmware versions, deployment conditions and components so remediation and user communication can be targeted accurately.
Check Integrated Components and Notify Maintainers
Article 13 requires manufacturers that identify a vulnerability in an integrated component to report it to the person or entity manufacturing or maintaining that component and to address the vulnerability in the finished product. The checklist should therefore include component ownership and maintainer-notification status.
Assess Risk and Prioritise Remediation
Record severity, exploitability, exposure, affected functions and the product context that informs remediation priority. Update the cybersecurity risk assessment where the vulnerability changes the product's risk picture rather than treating vulnerability triage as a separate operational system.
Track Mitigation and Permanent Remediation Separately
A temporary workaround can reduce immediate risk without eliminating the underlying issue. Track mitigation, permanent remediation, validation testing and release status separately so the organisation knows whether the vulnerability is actually closed.
Prepare and Distribute Security Updates
The readiness process should connect remediation to the build, signing, testing, release and distribution of security updates. Record the corrected version, affected versions, release date, installation guidance and any dependencies that users must satisfy.
Communicate Fixed Vulnerabilities and User Actions
Where the CRA requires vulnerability information and security-update communication, users need enough information to understand affected products, severity, impact and remediation. The vulnerability record should link to the advisory or customer communication rather than closing when engineering ships a fix.
Maintain Vulnerability Handling Through the Support Period
Article 13 requires effective vulnerability handling during the support period. The checklist should verify that supported versions remain visible to monitoring and remediation processes and that end-of-support transitions do not silently remove products from vulnerability tracking.
Escalate Potential Article 14 Triggers
Not every vulnerability is reportable under Article 14. The checklist should include an escalation step where there is reliable evidence of active exploitation or where a severe incident may have occurred. The reporting decision should be documented separately from the technical vulnerability record.
Retain Evidence From Intake to Closure
Preserve timestamps, validation findings, affected-version analysis, risk decisions, component communication, remediation work, test evidence, security-update releases, user communications and reporting assessments. This history supports lifecycle governance and technical documentation review.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.