CRA Vulnerability Handling:
7 Documents Manufacturers Need
for EN 40000-1-3

Your end-to-end internal process document for handling vulnerabilities — from receipt through to post-release. It must reflect the activities specified across 48 requirements of EN 40000-1-3 in the receipt, verification, remediation, release, and post-release phases, covering what you will do at each phase, who is responsible, and within what timeframes.

For example, it must spell out that an acknowledgement will be sent to vulnerability reporters within a defined timeframe, how severity is assessed, and how and when security updates are released.

Also known as "Vulnerability Disclosure Policy"

The external-facing counterpart to the Vulnerability Handling Policy. It communicates to the outside world — researchers, customers, partners — how your organisation handles reported vulnerabilities. It must be publicly available on your website.

A practical example: your CVD policy might state "We acknowledge vulnerability reports within 5 business days." Internally, your Vulnerability Handling Policy will then document the exact process to make that happen.

You are required to maintain an SBOM in a commonly used, machine-readable format — either CycloneDX or SPDX. It must contain a list of upstream interdependencies, including open source, to facilitate timely resolution of issues when a vulnerability is identified.

Maintaining your SBOM and actively monitoring the components it lists enables you to discover vulnerabilities on an ongoing basis, directly supporting requirements in the Receipt phase ([RCP-2-RQ-01], [RCP-2-RQ-02], [RCP-3-RQ-01]).

Alongside the SBOM, manufacturers must maintain a documented list of hardware components contained in their products. Similar to the SBOM, this enables you to monitor vulnerabilities during the Receipt phase ([RCP-4-RQ-01]) and address them in a timely manner.

A risk-based document that defines how, how often, and through which methods you test and review the security of your products. It must specify which types of tests you perform, which tools and methodologies applied, and at what frequency.

Critically, this is not a document you create once and forget. You must maintain evidence that you are actually executing the plan. Auditors will want to see proof of ongoing activity, not just the plan itself.

When a vulnerability is reported, you must document the steps you took to verify it — what you assessed, what evidence you gathered, and what conclusion you reached.

This record is your proof that verification was performed rigorously and systematically, rather than informally.

If a vulnerability is reported to you, verified as affecting your product, and subsequently fixed, you are required to publish a security advisory on your website. It must be published in a human-readable format. A machine-readable format (CSAF) is only required if your risk assessment determines it is necessary.

It must include a description of the vulnerability, the affected product version(s), the severity and impact, and clear guidance for users on how to remediate it.