CRA technical documentation is the structured evidence package supporting the manufacturer's conformity conclusion. It must be drawn up before the product is placed on the market and continuously updated where appropriate, at least during the support period. Annex VII defines minimum content, but manufacturers can retain additional product-specific evidence needed to explain architecture, controls, risk decisions, verification and vulnerability handling.
Article 31 Defines the Technical Documentation Obligation
Article 31 requires the technical documentation to 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 in Annex I. It must contain at least the elements listed in Annex VII. The documentation therefore needs to cover both the security properties of the product and the vulnerability-handling processes maintained by the manufacturer.
- Document the product.
- Document the means used to satisfy Annex I Part I.
- Document vulnerability-handling processes under Part II.
- Include at least the applicable Annex VII elements.
- Keep evidence connected to the actual product version.
Technical Documentation Must Be Drawn Up Before Market Placement
Article 31 requires the technical documentation to be drawn up before the product with digital elements is placed on the market. This means manufacturers should not treat the technical file as something that can be assembled only after commercial release. Architecture records, risk assessments, vulnerability-handling specifications and verification reports should be available in time to support the applicable conformity assessment and release decision.
- Prepare the documentation before market placement.
- Align documents with the release candidate.
- Resolve missing evidence before conformity assessment.
- Avoid retrospective reconstruction after release.
Technical Documentation Must Be Updated
Article 31 also requires technical documentation to be continuously updated where appropriate, at least during the support period. A new software version, architecture change, vulnerability-handling process change, new standard, material security fix or revised risk conclusion can make older documentation incomplete. Manufacturers should define update triggers and maintain enough version history to determine which documentation corresponds to which product release.
- Update for material architecture changes.
- Update for compliance-relevant software versions.
- Update affected risk assessments.
- Update vulnerability-handling evidence.
- Maintain product-to-document version traceability.
Annex VII Starts With a General Product Description
Annex VII requires a general description of the product with digital elements. This includes its intended purpose, versions of software affecting compliance with essential cybersecurity requirements and, for hardware products, photographs or illustrations showing external features, marking and internal layout. It also includes the user information and instructions required by Annex II. Product identification should be precise enough that reviewers can determine which marketed configuration the evidence covers.
- Intended purpose.
- Compliance-relevant software versions.
- Hardware photographs or illustrations where applicable.
- External features and marking where applicable.
- User information and Annex II instructions.
Annex VII Requires Design and Development Information
Annex VII requires necessary information on the design and development of the product. Where applicable, this includes drawings and schemes and a description of system architecture explaining how software components build on or feed into each other and integrate into the overall processing. The required depth depends on the product, but the documentation should allow a reviewer to understand the security-relevant design rather than merely list component names.
- Design information.
- Development information.
- Relevant drawings and schemes.
- System architecture.
- Software component relationships.
- Integration into overall processing.
Vulnerability Handling Must Be Documented
Annex VII specifically requires information and specifications about the vulnerability-handling processes put in place by the manufacturer. The listed information includes the software bill of materials, coordinated vulnerability disclosure policy, evidence that a contact address has been provided for reporting vulnerabilities and a description of the technical solutions chosen for secure distribution of updates. This documentation should describe how the operational vulnerability-handling system works rather than merely state that the manufacturer has one.
- Software bill of materials.
- Coordinated vulnerability disclosure policy.
- Vulnerability reporting contact evidence.
- Secure update-distribution solution.
- Related vulnerability-handling specifications.
Production and Monitoring Processes Are Part of Annex VII
Annex VII requires necessary information and specifications for the production and monitoring processes of the product and validation of those processes. This can include controls ensuring that production builds, configurations and vulnerability-handling processes remain aligned with the assessed product design. The exact evidence depends on the product and development model, but manufacturers should be able to explain how production and monitoring preserve conformity rather than assuming that a secure development design automatically survives the production process.
- Production process information.
- Monitoring process information.
- Process specifications.
- Process validation evidence.
- Release and production security controls.
The Cybersecurity Risk Assessment Must Be Included
Annex VII requires an assessment of the cybersecurity risks against which the product is designed, developed, produced, delivered and maintained pursuant to Article 13, including how the Annex I Part I essential cybersecurity requirements apply. Article 13 also expressly requires the cybersecurity risk assessment to be included in the Article 31 technical documentation. The assessment should therefore be identifiable as part of the technical-documentation set and connected to the relevant product version.
- Include the Article 13 cybersecurity risk assessment.
- Identify applicable Annex I requirements.
- Connect the assessment to the product version.
- Include clear non-applicability justification where required.
Support-Period Information Must Be Included
Annex VII requires relevant information taken into account to determine the support period pursuant to Article 13. Support-period evidence can therefore include product use expectations, dependency support, update capability and other factors considered when the manufacturer determined the period. The documentation should preserve the reasoning supporting the declared period rather than only record an unexplained end date.
- Support-period determination.
- Relevant product-use assumptions.
- Maintenance considerations.
- Dependency considerations.
- Update and vulnerability-handling capability.
Document Applied Standards and Other Technical Solutions
Annex VII requires a list of harmonised standards applied in full or in part, applicable common specifications or qualifying European cybersecurity certification schemes. Where those routes have not been used, the documentation should describe the solutions adopted to meet the applicable Annex I requirements and list other relevant technical specifications applied. Where standards or other recognised specifications are applied only partly, the documentation should identify the parts used.
- Applied harmonised standards.
- Applied common specifications.
- Relevant certification schemes where applicable.
- Other technical specifications.
- Alternative solutions used to meet Annex I.
- Parts applied where use is partial.
Include Reports of Conformity Tests
Annex VII requires reports of tests carried out to verify conformity of the product and the manufacturer's vulnerability-handling processes with the applicable essential cybersecurity requirements in Annex I Parts I and II. The technical-documentation set should therefore make it possible to connect test evidence to requirements, product versions and security controls. A list saying penetration test completed is weaker than an identifiable report showing scope, configuration, method, findings and result.
- Product security test reports.
- Vulnerability-handling process verification.
- Applicable Annex I references.
- Product version and configuration.
- Results and remediation status.
Include the EU Declaration of Conformity
Annex VII requires a copy of the EU declaration of conformity. The declaration is therefore part of the technical-documentation package rather than an entirely separate compliance artefact. It should correspond to the product and conformity conclusion supported by the rest of the documentation. Version and product identifiers should be managed so that the declaration is not accidentally associated with evidence for a different release.
- Copy of the EU declaration of conformity.
- Correct product identification.
- Consistent version information.
- Traceability to the supporting technical evidence.
Understand the Two SBOM References in Annex VII
Annex VII includes the SBOM within the required documentation of vulnerability-handling processes. It also separately refers to the SBOM in the context of a reasoned request from a market surveillance authority where necessary for checking compliance with Annex I. Manufacturers should therefore avoid interpreting the authority-request wording as meaning that no SBOM needs to be prepared unless an authority asks for one. Annex I Part II independently requires manufacturers to identify and document components and draw up an SBOM covering at least top-level dependencies.
- Maintain the SBOM as part of vulnerability handling.
- Connect it to applicable product versions.
- Understand the separate authority-request provision.
- Do not wait for an authority request before creating the Annex I SBOM.
Technical Documentation Can Reference Controlled Evidence
The technical documentation does not have to be one enormous static document if the manufacturer's controlled system reliably identifies and preserves the required evidence. A technical file can index architecture diagrams, risk assessments, test reports, SBOMs, vulnerability procedures, standards mappings and release records stored in controlled repositories. References should remain stable and accessible throughout the required retention and support lifecycle. Avoid links that become unusable when a project-management ticket is closed or a temporary build system is deleted.
- Use controlled evidence repositories.
- Use stable document identifiers.
- Maintain access and retention.
- Preserve version history.
- Avoid temporary evidence locations.
The Technical File Should Identify Applicable Requirements
Technical documentation is strongest when reviewers can move from an Annex I requirement to the manufacturer's implementation and then to verification evidence. A requirements matrix can provide that navigation. It can identify the legal reference, applicability decision, design or process control, technical document, verification activity and result. The CRA does not prescribe one mandatory traceability-matrix format, but the resulting structure can make conformity assessment substantially easier.
- Annex I requirement.
- Applicability decision.
- Control or process.
- Evidence reference.
- Verification result.
- Product version.
Keep Technical Documentation Aligned With Product Changes
Technical documentation can become inaccurate even when every original document was correct. New software versions can alter architecture, dependencies, security controls or vulnerability-handling behaviour. Manufacturers should include documentation impact in product-change review. Each material change should identify which risk assessments, architecture records, test reports, standards mappings and declarations require revision. Article 31's update obligation makes documentation maintenance part of the compliance lifecycle.
- Review documentation impact for product changes.
- Update affected architecture records.
- Update risk and test evidence.
- Update standards mappings where necessary.
- Maintain release-specific traceability.
A Practical Annex VII Technical Documentation Index
A practical technical-documentation index can organise the required material into product identification, intended purpose and user information, architecture and design, production controls, vulnerability handling, cybersecurity risk assessment, support-period determination, applicable standards and technical solutions, security and conformity tests, declaration of conformity and SBOM evidence. The index should identify document owners, versions and evidence locations. The exact internal file structure is the manufacturer's choice as long as the required information is complete, controlled and usable for conformity assessment and regulatory review.
- Product description and intended purpose.
- Compliance-relevant versions.
- Annex II user information.
- Architecture and design documentation.
- Production and monitoring processes.
- Vulnerability-handling documentation.
- Cybersecurity risk assessment.
- Support-period evidence.
- Standards and technical solutions.
- Test reports.
- EU declaration of conformity.
- SBOM evidence.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.