CRA release evidence checklist for software

Is a release bundle a legal requirement?

The CRA requires technical documentation and supporting evidence, not a ZIP file with a prescribed folder structure. Article 31 and Annex VII set the documentation requirements; Article 13 connects the risk assessment, vulnerability handling and retention duties. The bundle described here is ConformOps's suggested way to organise that work for software releases.

The distinction matters. Passing this checklist cannot establish conformity by itself, and a technically complete archive cannot supply a missing manufacturer decision or external assessment. Use the record to expose what is available and what is still required, then apply the conformity route appropriate to the product.

1. Identify the product and what actually shipped

Create one release identity that appears in the evidence index, build record, SBOM, tests and technical-file update. Record the product, version, source revision, build identifier and artifact digest. Include the target platform or edition when the delivered dependencies or security behaviour differ. A tag that can move should not be the only reference to the assessed source.

Distinguish the build from the shipped package. An installer may include a runtime absent from the application manifest; a container can add operating-system packages; an enterprise edition can enable a privileged feature. Describe the delivered boundary and account for packaging steps after compilation. Where a remote service provides a product function, preserve the relevant configuration and service-version evidence without collecting unrelated infrastructure data.

2. Retain the component inventory and its limits

Attach the release SBOM and record its producer, format, creation time, artifact relationship and known gaps. Reconcile it with the build and packaging evidence. The CRA minimum concerns at least top-level dependencies; a practical investigation often needs deeper coverage. The SBOM guide separates that legal minimum from completeness checks.

Keep exact versions where known and mark unresolved constraints, vendored code or unsupported package sources as unknown. An SBOM that passes a parser check can still omit a shipped native library. Record that limitation instead of converting structural validity into an assertion that the inventory is complete.

3. Connect tests to the claims they support

For each security check, retain the tool or test version, configuration, scope, execution time, outcome and durable result reference. Explain which requirement or risk it addresses. An authentication test and a dependency lookup answer different questions; neither should stand in for the whole cybersecurity risk assessment.

Record failures and incomplete coverage explicitly. If a vulnerability service was unavailable, the result is unknown for that check. If tests ran before a packaging change, explain whether they still cover the final artifact or rerun the affected tests. A green CI badge without its scope is weak evidence when someone later asks what the release actually demonstrated.

4. Keep decisions separate from observations

Attach product affectedness investigations, residual-risk decisions, requirement-gap status and any reporting review to the product version and evidence considered. Name the decision maker and preserve the rationale. An advisory match is an observation; a product-specific not-affected conclusion requires investigation; Article 14 reporting is another decision with its own criteria.

Also retain classification and route decisions, and any required external assessment or certification results. A team cannot approve away a mandatory requirement. Do not represent generated text or a software-generated approval flag as a notified-body result or authorised manufacturer signature.

5. Index the documentation and operational commitments

The Annex VII guide describes the technical file. Link the release's product description, risk assessment, design evidence, standards mapping, test results and support-period rationale to that structure. Keep user instructions and the declaration separately identifiable, with draft and signed states visible.

Include the vulnerability contact, update instructions, support end date and release notes that users receive. Apply retention deliberately: Article 13(13) sets at least ten years after placing on the market or the support period, whichever is longer, for technical documentation and the declaration. Issued security updates have the separate availability rule in Article 13(9). A short CI artifact-expiry setting may not meet those needs.

A worked handoff for release 2.8.0

Imagine a team shipping a desktop client that upgrades its document parser. Engineering provides the immutable source revision, installer digest, build record, SBOM and parser regression results. The evidence owner checks that the SBOM describes the installer rather than an earlier development build and links the results to the relevant input-validation risk.

An advisory review records which earlier versions are affected, what 2.8.0 changes and how users receive the fix. The accountable owner reviews any changed risks and the separate reporting question where triggered. The release documentation is updated, while the 2.7.0 evidence remains intact. If the final vulnerability lookup fails, the record says so and names the follow-up; it does not claim that no vulnerabilities were found.

• Evidence index: release identity, requirement/risk locator, artifact reference, date and owner.
• Integrity: file hashes and controlled access; a matching hash proves byte consistency, not correctness of the claim.
• Review state: observed, incomplete, under review or decided, with unresolved actions visible.
• Handoff: named recipient, next action and the condition that makes the release record ready for its intended review.

Where ConformOps fits

ConformOps connects release-bound source and component evidence to requirements, risks, review history and controlled documentation drafts. It supports the evidence index and preserves lineage across assessments. Security tools still perform their checks, engineers implement and verify controls, and authorised people remain responsible for decisions.

Start with one real release and try to reconstruct it from the proposed bundle. Missing packaging evidence, expired test artifacts or unclear approval scope become specific tasks. That exercise is more useful than increasing document volume without improving the connection between a claim and its evidence.