Short answer
An EU technical file must document the product design, the risk assessment, the applicable legislation and harmonised standards, test reports and calculations, and the conformity assessment performed. It must be retained for ten years after the last unit is placed on the market and produced to market surveillance authorities on request.
What is the technical file?
The technical file, sometimes called technical documentation, is the documented evidence that a product meets the applicable EU requirements. It is the manufacturer responsibility and the first thing a market surveillance authority asks to see.
The concept comes from the New Legislative Framework (Decision No 768/2008/EC), which provides model provisions used across harmonisation directives. Each directive contains an annex describing the technical documentation for its conformity assessment modules, but the core structure is consistent.
The file must be drawn up before the product is placed on the market. It is not a marketing document. It is an engineering record.
What must the technical file contain?
The typical contents, drawn from the NLF model provisions, are:
- Product description. A general description of the product, including its intended use, variants, and models covered.
- Design documentation. Conceptual design and manufacturing drawings, descriptions of components, and explanations necessary to understand those drawings.
- Applicable legislation. A list of the EU harmonisation laws the product complies with.
- Standards applied. A list of harmonised standards applied in full or in part, with references. Where harmonised standards have not been applied, a description of the solutions adopted to meet the essential requirements.
- Risk assessment. The documented analysis of hazards and the measures taken to address them, following the priority order: inherently safe design, protective measures, information for users.
- Test reports. Results of design calculations, examinations carried out, and test reports from internal or external laboratories.
- Conformity assessment records. Evidence of the assessment performed, including notified body certificates or decisions where the module requires involvement.
- [EU Declaration of Conformity](/glossary/eu-declaration-of-conformity). A copy of the signed declaration.
- Labelling and instructions. Copies of the marking, labelling, and instructions as supplied with the product.
How should the file be structured?
There is no mandated file format, but authorities expect a coherent, navigable record. A practical structure:
| Section | Contents |
|---|---|
| A. Product identification | Description, models, variants, photos |
| B. Legal basis | Applicable directives, standards list |
| C. Risk assessment | Hazard analysis, mitigation measures |
| D. Design evidence | Drawings, schematics, component lists |
| E. Test evidence | Test reports, calculations, lab credentials |
| F. Assessment records | Module followed, notified body documents if any |
| G. Market documents | Declaration of Conformity, labels, instructions |
Each section should be dated and version-controlled. When the product changes, the file must be updated and the conformity reassessed.
Who keeps the file and for how long?
The manufacturer draws up and keeps the technical documentation. Importers must ensure the manufacturer has done so and must keep a copy of the EU Declaration of Conformity available.
The retention period is ten years from the date the last unit of the product model is placed on the market. For some sector laws the period differs, so check each applicable act.
The file must be made available to market surveillance authorities on request, in a language they can understand. Authorities can request it during inspections or following an incident.
Common technical file failures
* No risk assessment. The most frequent gap. Test reports alone do not constitute a file without the documented hazard analysis. * Standards listed but not applied. Citing a harmonised standard without evidence it was actually followed. * Outdated after design changes. The file reflects the original design but the product has since changed components or suppliers. * Missing importer verification. The importer cannot produce the file because the manufacturer never provided access. * Wrong language. The file exists but the authority cannot evaluate it.
Checklist: technical file readiness
* [ ] Product description covers all models and variants placed on the market * [ ] Every applicable directive is listed with its scope justification * [ ] Harmonised standards are listed with version dates and extent of application * [ ] A documented risk assessment addresses all foreseeable hazards * [ ] Test reports are traceable to the product configuration tested * [ ] The EU Declaration of Conformity is signed, dated, and matches the file * [ ] Labels and instructions as shipped are filed as copies * [ ] A change-control process keeps the file current with the product
How detailed must the risk assessment be?
The risk assessment is the analytical core of the technical file, and authorities examine it closely. A adequate assessment follows a recognisable method:
- Identify hazards. List every hazard associated with the product across its lifecycle: mechanical, electrical, thermal, chemical, and for connected products, cybersecurity-related hazards affecting safety.
- Identify exposed persons. Consider intended users and reasonably foreseeable users, including children, older people, and persons with disabilities where relevant.
- Estimate risk. For each hazard scenario, estimate severity and probability using a documented scale.
- Apply the hierarchy. Address risks through inherently safe design first, then protective measures, then information for users. Document why each level was or was not sufficient.
- Verify residual risk. Confirm the remaining risk is acceptable and that warnings address what design could not eliminate.
- Record the conclusion. State the overall safety conclusion with reference to the evidence.
Standards such as EN ISO 12100 for machinery illustrate the method, but the principle applies generally. The assessment must be specific to the product, not a generic template with the product name inserted.
How do test reports fit into the file?
Test reports are evidence, not conclusions. Each report in the file should be traceable:
* The report identifies the product configuration tested: model, version, components * The test method references the standard and its version * The laboratory is identified, with accreditation where relevant * The results are linked to the requirement they demonstrate
Where testing was performed on a representative model covering a family of variants, the file must justify why the tested configuration represents the others. Unjustified family coverage is a common finding.
For tests performed in-house rather than by an external laboratory, the file should describe the test setup, calibration of equipment, and competence of personnel. In-house testing is acceptable where the directive permits it, but the evidence standard is the same.
How should software and firmware be documented?
For products with safety-relevant or radio-relevant software:
* Record the software version assessed and its identification method * Describe the software architecture at a level sufficient to understand safety functions * Document verification activities: testing, review, or analysis performed * Define the change process: which modifications trigger reassessment and which do not * For radio equipment, address the software security requirements that prevent non-compliant reconfiguration
Firmware updates after placing on the market are a known enforcement focus. A product whose update mechanism allows installation of non-compliant radio parameters may be found non-compliant even if the shipped version was assessed correctly.
How should the file address products with multiple variants?
Product families with variants in colour, size, or minor features are common. The file strategy should balance completeness with proportionality.
Define the family. Document the criteria for family membership: shared design, materials, manufacturing process, and hazard profile. Variants differing only in cosmetic features typically belong to one family.
Assess the worst case. Where variants differ in a safety-relevant parameter, such as size affecting mechanical hazards or power affecting thermal hazards, assess the worst-case variant and justify why it bounds the others.
List all variants. The file should enumerate the models covered, with their identifiers, so an authority can confirm that the product in front of them is within the assessed family.
Control family expansion. New variants should be checked against the family criteria before being added. A variant that introduces a new hazard or changes the worst case requires reassessment.
Uncontrolled family growth is a common file weakness. A family that has expanded far beyond its original assessment without review will not survive scrutiny.
What language requirements apply to the technical file?
The technical file itself does not have a general EU language requirement comparable to consumer-facing information, but practical considerations apply:
* The file must be understandable to the market surveillance authority reviewing it. In practice, this means the language of the member state where the inspection occurs, or English where the authority accepts it. * Test reports from international laboratories are commonly in English and generally accepted. * Declarations of Conformity must be translated into the languages required by the member states where the product is made available.
For sellers operating across many member states, maintaining the core file in English with translations of the Declaration and safety information is the standard approach. Confirm language acceptance with the relevant authorities where the product is primarily sold.
How do you handle legacy products with incomplete files?
Sellers often discover that products already on the market have incomplete or missing technical files. The remediation approach:
- Prioritise by risk. Products with higher hazard potential or larger installed base come first.
- Reconstruct the file. Gather existing evidence: design records, test reports, supplier declarations. Commission new testing where evidence is missing for safety-relevant requirements.
- Perform a retrospective risk assessment. Assess the product as currently manufactured, documenting the hazards and the basis for the safety conclusion.
- Address gaps found. If the reconstruction reveals non-compliance, correct it through design change, labelling update, or market action as appropriate.
- Document the remediation. Record what was reconstructed and when, so the file history is transparent.
Do not backdate documents. A reconstructed file should be dated as reconstructed. Authorities prefer an honest recent file to a file with implausible contemporaneous dates.
Sources
* Decision No 768/2008/EC, New Legislative Framework: https://eur-lex.europa.eu/eli/dec/2008/768 * The Blue Guide on EU product rules: https://single-market-economy.ec.europa.eu/docs/single-market/goods/blue-guide_en * Regulation (EC) No 765/2008: https://eur-lex.europa.eu/eli/reg/2008/765