What is a technical file?

Last reviewed: 11 September 2026~7 min read

A technical file is the evidence that your product meets EU law — kept by you, not filed with anyone. You draw it up before placing the product on the market, you keep it for ten years, and you produce it if a market surveillance authority asks. It is the difference between claiming conformity and being able to demonstrate it.

The most common misunderstanding. There is no EU portal where you upload a technical file. There is no authority that reviews and approves one in the ordinary case. This surprises people who expect compliance to feel like a filing. The consequence is that nobody tells you your file is inadequate until the moment when that is an expensive thing to discover.

The pattern, across every regulation

EU product legislation has used the same architecture since the New Approach of the 1980s, and once you see it, every regulation becomes readable:

  1. Essential requirements — outcomes the product must achieve, written in an annex, deliberately technology-neutral.
  2. Harmonised standards — voluntary technical specifications that, when applied, give a presumption of conformity with those requirements.
  3. Conformity assessment — the procedure by which you establish the product complies. Self-assessment for most products; a notified body for higher-risk categories.
  4. Technical documentation — the evidence trail, kept by you.
  5. Declaration of conformity — your signed statement.
  6. CE marking — the visible claim.

The names change between regulations. The structure does not.

What goes in one

The specific contents come from the annex of the regulation that applies to you. But the shape is consistent:

Typical technical file sections and their purpose
SectionPurpose
Product descriptionWhat the product is, its intended use, its versions or models, and its foreseeable misuse.
Design and constructionDrawings, architecture, schematics, and the explanations needed to understand them.
Risk assessmentThe hazards or threats identified, the risks evaluated, and the measures adopted.
Requirement-to-evidence indexEach applicable essential requirement mapped to the evidence that satisfies it. The single most useful page in any file.
Standards appliedDated references, and which requirements each standard covers.
Test reportsWhat you tested, how, what you found, what you did about it.
Production controlsHow you ensure the units you actually ship match the one you assessed.
InstructionsA copy, as supplied to the user.
Declaration of conformityA copy of the signed declaration.

By regulation

How long you keep it

Ten years after the product is placed on the market, as a general rule. Under the Cyber Resilience Act, ten years or the support period, whichever is longer — which for a product with a long support commitment means longer than ten. For series production, the clock runs from the last unit placed on the market.

Practical advice that applies to every regulation

  1. Build the index first. Start with the list of applicable essential requirements and fill in evidence against it. A file assembled the other way round — documents first, mapping later — always has gaps, and the gaps are invisible until someone reads it adversarially.
  2. Record the "not applicable" decisions. Requirements you judged inapplicable need a one-line reason. This is the cheapest insurance in compliance.
  3. Write it during development. The evidence is generated as a by-product of doing the engineering properly. Captured then, it is nearly free; reconstructed later, it is expensive and worse.
  4. Assume an adversarial reader. Not because authorities are hostile, but because that is the standard that produces a file which holds up.
  5. Keep it retrievable by someone other than its author. Ten years is longer than most people stay in a job.