SAMMY works best on screens 1024px wide or larger.
CRA Framework
Browse CRA Framework
TD: Technical Documentation
TD: Has technical documentation been drafted?
  • Technical documentation is finalized and version-controlled before the product is placed on the EU market
  • Documentation covers all required elements: risk assessment, threat model, security requirements, architecture, SBOM, test results, vulnerability handling processes, and conformity assessment procedure
  • A defined owner and process exists for keeping the documentation current when the product changes
  • Documentation is stored in a central, access-controlled repository with an audit trail, and can be produced to authorities within a reasonable and defined timeframe
  • Where product families share documentation, the shared documentation clearly identifies which variants it covers and documents variant-specific differences
Not applicable - The activity is not relevant to the product type or architecture.
Not implemented - No structured or repeatable approach exists.
Partially implemented - The activity exists but is incomplete, inconsistently applied, or does not meet all quality criteria.
Fully implemented - A defined and repeatable approach exists and meets the stated quality criteria.
Description

The Cyber Resilience Act (Article 31 and Annex VII) requires manufacturers to draw up technical documentation before the product with digital elements is placed on the EU market, and to keep it up to date throughout the product's expected lifetime or the support period, whichever is longer. Technical documentation is the single artifact that ties together all other controls in this framework; it is the comprehensive record through which the manufacturer demonstrates that the product meets the essential cybersecurity requirements and has undergone the applicable conformity assessment procedure.

Produce technical documentation that covers all required elements as set out in Annex VII. This includes the general description of the product, the risk assessment, the threat model, security requirements, architecture and design information, the software bill of materials (SBOM), test results, the vulnerability handling process, and a description of the conformity assessment procedure applied. Each of these areas corresponds to a control in this framework, meaning that an organization scoring well across the framework is effectively assembling the evidence base for its technical documentation. The documentation must be finalized and version controlled before the product is placed on the market, ensuring that a complete and coherent record exists at the point of market entry.

Maintain and update the documentation throughout the product's support period to reflect material changes to the product, its risk profile, or its security posture. Ensure the documentation is retained in a form that can be made available to market surveillance authorities upon reasoned request (Article 52(3)), for a period of ten years after the product is placed on the market or the end of the support period, whichever is longer. Treat technical documentation not as a bureaucratic obligation but as a living body of evidence that reflects the actual security state of the product at any given point in time.