CRA technical documentation checklist
Sytance · Updated
CRA technical documentation is the evidence file for the product and the manufacturer's cybersecurity processes. It must show how the product meets Annex I and how the manufacturer handles vulnerabilities.
Documentation duty
The technical documentation shall contain all relevant data or details of the means used by the manufacturer to ensure that the product with digital elements and the processes put in place by the manufacturer comply with the essential cybersecurity requirements set out in Annex I. It shall at least contain the elements set out in Annex VII.
Regulation (EU) 2024/2847, Article 31(1)
Article 31 requires the file to explain how the product and the manufacturer’s processes comply with Annex I. The documentation therefore includes both the product design and the arrangements for handling vulnerabilities after release.
Product and process evidence
The product cybersecurity properties in Annex I, Part I, and the vulnerability-handling process in Annex I, Part II.
Timing and updates
The technical documentation shall be drawn up before the product with digital elements is placed on the market and shall be continuously updated, where appropriate, at least during the support period.
Regulation (EU) 2024/2847, Article 31(2)
The technical documentation must exist before placing on the market. It must then be kept current when changes matter during the support period.
- A changed product design, architecture, software version, or update method can require an update.
- A changed cybersecurity risk assessment can require an update.
- New vulnerability information can require an update.
- A redesigned or reassessed product should have documentation that identifies the changed versions.
Annex VII contents
Annex VII is the minimum content list. It is best read as evidence categories, not as a table template. The exact detail depends on the relevant product.
The file identifies the product, its intended purpose, the software versions that affect compliance, hardware images when relevant, and the user information in Annex II.
Annex VII asks for design, development, production, and vulnerability-handling information. This includes architecture, component relationships, the SBOM, disclosure policy, reporting contact and secure updates, together with production and monitoring processes and their validation.
The cybersecurity risk assessment is part of the file. Annex VII also asks for the information used to determine the support period.
The file records standards, common specifications, certification schemes, other technical solutions, test reports, and the EU declaration of conformity.
Annex VII includes the SBOM when a market surveillance authority makes a reasoned request and the SBOM is needed to check compliance with Annex I.
An Annex VII checklist for a product release
The following index follows the eight Annex VII entries. It is an example of how to organise the information, not a prescribed folder structure or a requirement to export eight separate files. Each referenced record should identify the product and version to which it applies.
- Product description: purpose, software versions affecting compliance, relevant hardware images and markings, and Annex II user information.
- Design and processes: architecture and component relationships; vulnerability handling, SBOM, disclosure policy, reporting contact and secure updates; production, monitoring and process validation.
- Cybersecurity risk assessment: the product risks and reasoning about the applicability of Annex I, Part I requirements.
- Support period: the information used to determine its duration.
- Standards and technical solutions: applied provisions, their status and extent of use, and the solutions used for requirements they do not cover.
- Verification reports: tests of the product and the vulnerability-handling processes against applicable essential requirements.
- EU declaration of conformity: the declaration corresponding to the assessed product.
- SBOM on authority request: the applicable SBOM when a market surveillance authority makes a reasoned request and needs it to check Annex I compliance.
For a fictional controller release 1.2, the index could point to the release description, architecture revision, risk assessment, SBOM, update tests and user instructions for that release. A newer risk assessment paired with an older firmware test report needs an explanation of whether the tested controls still apply.
Check completeness against the applicable Annex VII information and the product version being assessed. A document index helps reviewers find the analysis and results behind each conclusion, including any information still missing.
Evidence links
The risk assessment explains the chosen security measures; component records identify the software those measures protect; vulnerability-handling records show what happens when a new issue is found. The following pages explain the content and use of each record.
Risk assessment
Shows how Article 13 and Annex I apply to the product. Read Cybersecurity Risk Assessment.
Gap analysis
Compares current product evidence with applicable CRA requirements. Read Gap Analysis.
SBOM and components
Supports vulnerability handling and component visibility. Read SBOM and Component Records.
Vulnerability records
Shows vulnerability intake, remediation, disclosure, updates, and testing. Read Vulnerability Handling Records.
Risk assessment
Article 13(4) puts the cybersecurity risk assessment into the technical documentation. The risk assessment explains how Annex I applies to the product, including why a product-property requirement is not relevant if that is the manufacturer's conclusion.
The Commission FAQ says the file must be available when the product is placed on the market, whether it is made inside or outside the EU. It also says later redesigns and reassessments should be reflected in the technical documentation.
Conformity and authority use
Technical documentation is mainly for conformity assessment and market surveillance. The Commission FAQ states that it does not normally have to be made available to customers or the public.
The main public exception described in the FAQ concerns certain important free and open-source software products using the Article 32(5) self-assessment route.
Documentation must support conformity checks
A market surveillance authority may request the information needed to demonstrate conformity. Missing or unclear documentation can become a formal compliance problem.