What it is
The technical documentation is the evidence file behind your CE marking. Article 31 requires you to draw it up before placing the product on the market, keep it up to date, and keep it at the disposal of market surveillance authorities for ten years after placing on the market or for the support period, whichever is longer.
Annex VII prescribes eight points. They are not suggestions about structure — an assessor will work down the Annex looking for each one, so the sensible thing is to structure your file in exactly that order and label each section with its Annex VII point number.
The eight sections
| Point | What it requires | What people get wrong |
|---|---|---|
| 1 | General description: intended purpose, the software versions affecting compliance, photographs for hardware, and the Annex II user information. | Describing the product for someone who already knows it. Write it for a stranger. |
| 2 | Design, development, production and vulnerability handling: system architecture, the SBOM, the CVD policy, the vulnerability contact address, and how updates are securely distributed. | Saying "we use TLS" for update security. The control is signature verification on the client; TLS alone does not stop a compromised distribution server. |
| 3 | The cybersecurity risk assessment, including how each Annex I Part I requirement applies and how it is implemented. | Submitting a risk register with no link to the essential requirements. The linkage is what this section is for. |
| 4 | The information taken into account to determine the support period. | Stating a period with no reasoning. If it is under five years you must justify it; over five years, say what you considered anyway. |
| 5 | Harmonised standards applied, or a description of the solutions adopted instead. | Assuming you must apply a standard. You need not — but then you must describe your own solutions, requirement by requirement. |
| 6 | Reports of the tests carried out to verify conformity of both the product and the vulnerability handling processes. | Providing only a dependency scan. That evidences one requirement; the design-level ones need their own evidence. |
| 7 | A copy of the EU declaration of conformity. | Forgetting it, or including an unsigned draft. |
| 8 | The SBOM, on a reasoned request from a market surveillance authority. | Treating this as optional altogether. You must have the SBOM under Annex I Part II point 1 regardless; point 8 only governs when you hand it over. |
The single most common finding
How long it needs to be
There is no page count. A single-product software vendor with a clean architecture can produce a defensible file in 30 to 60 pages, most of which is the requirement-by-requirement implementation record and the component inventory.
Length is not the measure. Traceability is: every claim you make should be tied to a provision, and every provision should be answered somewhere an assessor can find it.
Keeping it current
The obligation is continuing. A file drawn up once and left alone fails Article 31 the moment the product changes materially, and a substantial modification makes the product a new product requiring fresh conformity assessment.
In practice the parts that go stale fastest are the SBOM and the vulnerability position, because they change every time you bump a dependency. That is the argument for generating both from the build rather than maintaining them by hand.