Technical documentation (Annex VII) in practice

What Annex VII requires

The technical documentation must contain all relevant data and details of the means used to ensure conformity. Concretely:

1. General description of the product: intended purpose, versions, photos or drawings of external features, marking, and the user information and instructions.
2. Design, development, production and vulnerability handling process description, including: the SBOM; the coordinated vulnerability disclosure policy; contact addresses for reporting; and the processes and tooling for secure distribution of updates.
3. The cybersecurity risk assessment, including how the essential requirements are addressed.
4. The support period and its justification.
5. A list of harmonised standards applied in full or in part, with references; where not applied, a description of the solutions adopted to meet the essential requirements.
6. Reports of tests carried out to verify conformity and the effectiveness of vulnerability handling.
7. A copy of the EU declaration of conformity.

Structure that survives

Do not write it as one 200-page Word file. Build it as a versioned repository with a stable index:

/tech-doc
  00-index.md                 pointer to every artefact and its version
  01-product-description.md
  02-classification-memo.md   why default / Class I / Class II
  03-risk-assessment.md
  04-annex-i-matrix.md        requirement -> implementation -> evidence
  05-process/                 SDLC, disclosure policy, update process
  06-sbom/                    one per release, keyed by build id
  07-test-reports/            SAST, fuzzing, pentest, hw checklist
  08-standards-applied.md
  09-support-period.md
  10-declaration-of-conformity.pdf
  11-user-information/

Store it next to the code, in the same version control, with a tag per release. When the auditor asks "which SBOM corresponds to the firmware in this device", the answer is a build identifier and a tag, not an archaeology project.

The Annex I matrix is the heart of it

One row per Annex I Part I and Part II requirement, with: applicability (and justification if not applicable), the design element implementing it, and links to the evidence. This single table is what a reviewer reads first and what makes gaps obvious to you while they are still cheap.

Keeping it current

The documentation must be updated as appropriate throughout the support period. Practical rule: any change that changes an answer in the matrix triggers a documentation update in the same pull request as the code change. Treat a doc update as part of the definition of done, or the file will be nine months stale the day you need it.

User information (Annex II)

Separate from, but referenced by, the technical file. Users must receive: the manufacturer's identity and contact, the point of contact for reporting vulnerabilities, the product identification including type and version, the intended use and known risks, the support period end date in a clear and understandable way, details of security updates and how to obtain them, and instructions for secure commissioning, decommissioning and secure data removal. This is user-facing text; write it for a technician, not a lawyer.