📄️ Purpose of Technical Documentation for Software Under CRA (Annex VII)
The Technical Documentation required by the Cyber Resilience Act (CRA) is the central pillar of your compliance argument. Its purpose is to provide a comprehensive, organized file demonstrating how your app, game, or software component meets the essential cybersecurity requirements.
📄️ Elements of Technical Documentation for Software: A Checklist
The Cyber Resilience Act's (CRA) Annex VII provides a clear structure for your Technical Documentation. For your game, app, or software, this translates into a specific set of documents and information you need to compile. Here's a checklist of the core elements.
📄️ General Description of the Software Product: Intended Purpose & Versions
The first part of your Technical Documentation, as outlined in Annex VII, point 1, is a general description of your software product. This section sets the stage, providing a high-level overview for anyone, like a market surveillance authority, reviewing your file.
📄️ Software Design, Development, and Production Process Overview
The Cyber Resilience Act (CRA) isn't just about your final software product; it's also about how you build it. Annex VII, point 2, requires your Technical Documentation to describe the design, development, and "production" processes. For software, "production" generally refers to your build, packaging, and release pipeline.
📄️ Software Vulnerability Handling Processes Documentation
A huge part of your Cyber Resilience Act (CRA) obligation is demonstrating you have a solid plan for handling vulnerabilities after your software is released. Annex VII, point 2(b), requires you to include "necessary information and specifications of the vulnerability handling processes put in place by the manufacturer" in your Technical Documentation.
📄️ Cybersecurity Risk Assessment Documentation for Software
The cybersecurity risk assessment is the cornerstone of your entire compliance effort under the Cyber Resilience Act (CRA). It is not an optional extra; a copy of this assessment is a mandatory component of your Technical Documentation.
📄️ Software Bill of Materials (SBOM) in Your Technical Documentation
The Software Bill of Materials, or SBOM, is a critical component of your vulnerability management process under the Cyber Resilience Act (CRA). Consequently, it's a key part of your Technical Documentation.
📄️ List of Harmonised Standards & Common Specifications Applied to Software
A key part of demonstrating compliance with the Cyber Resilience Act (CRA) is explaining the technical basis for your security measures. Your Technical Documentation must include a section detailing any official standards or specifications you've used.
📄️ Descriptions of Solutions if Standards Are Not Applied for Software
Using harmonised standards is a straightforward way to show compliance with the Cyber Resilience Act (CRA), but it is not the only way. The CRA provides flexibility for manufacturers, including developers of apps, games, and other software.
📄️ Reports of Software Security Tests Carried Out
Claims about your software's security are one thing; proof is another. The Cyber Resilience Act (CRA) requires you to back up your conformity claims with evidence. A key part of this evidence is the results from security tests you've performed.
📄️ Copy of the EU Declaration of Conformity for Software
After you've done your due diligence and are ready to declare your software compliant with the Cyber Resilience Act (CRA), you create and sign the EU Declaration of Conformity (DoC). This signed declaration is not just a standalone document; it must also be included as part of your comprehensive compliance file.
📄️ User Instructions for Software as Part of Technical Documentation
The information you provide to your users is considered a key part of your software product under the Cyber Resilience Act (CRA). As such, a copy of these instructions must be included in your Technical Documentation.
📄️ Information on Software Support Period Determination
Under the Cyber Resilience Act (CRA), you can't just pick a support period for your app, game, or software out of thin air. You need a rationale, and you need to document it. This information is a required element of your Technical Documentation.
📄️ Keeping Software Technical Documentation Up-to-Date and Available
Your Technical Documentation under the Cyber Resilience Act (CRA) is not a static artifact you create once and then archive. For any software product like an app or a game, it must be a living file that reflects the current state of your product and its compliance.
📄️ Language Requirements for Software Technical Documentation
When you compile the Technical Documentation for your app or game, you need to consider the language it's written in. The Cyber Resilience Act (CRA) has rules about this, though they are most relevant when a third-party conformity assessment is involved.
📄️ Simplified Technical Documentation for Micro & Small Software Enterprises
The Cyber Resilience Act (CRA) acknowledges that the administrative load of full-scale technical documentation can be heavy, especially for smaller players in the software market. To address this, the CRA includes a provision specifically for micro and small enterprises.