Technical documentation

# Technical documentation Technical documentation, often called the technical file, is the dossier in which a manufacturer records how a product was designed, assessed and verified for compliance. It is the evidence behind the declaration of conformity: when a market surveillance authority asks why a product is compliant, the technical documentation is the answer, and its quality determines the outcome of the inspection. ## Key facts - Technical documentation must demonstrate that the product meets the applicable essential requirements of each relevant legislation. - It is drawn up before the product is placed on the market and kept for 10 years after the last unit is placed. - Typical contents include design descriptions, risk assessments, the list of standards applied, test reports and the declaration of conformity. - The file must be made available to market surveillance authorities on request, often within short deadlines. - Importers must ensure the documentation exists and can be made available, even though the manufacturer draws it up. - For RoHS, EN IEC 63000 defines the documentation process; other sectors have their own expectations. - A complete, organised file shortens inspections and signals credible product governance; a missing file is itself non-compliance. ## What the file must contain While each directive lists its own requirements, the core of a technical file is consistent across EU product law. It starts with a general description of the product, including its intended use, variants and the identification that links the file to the physical goods. Design and manufacturing drawings, schematics, circuit diagrams and bills of materials show what the product is and how it is made. The compliance analysis is the heart of the file: the list of essential requirements, the harmonised standards or other technical solutions applied to each, and the risk assessment showing how hazards were identified and controlled. Test reports from internal or external laboratories provide the evidence, with the methods, results and the identification of the tested samples. For products with software, firmware versions and change records belong in the file. The file also holds the administrative evidence: the EU Declaration of Conformity, labelling artwork, instructions for use in each language version, supplier declarations for materials and components, and records of design changes with their compliance re-evaluation. For higher-risk products assessed by a notified body, the body's certificates and decisions are included. ## Risk assessment as the foundation The risk assessment is what turns a pile of test reports into a compliance argument. It should identify the hazards associated with the product across its lifecycle, from manufacturing and transport through normal use, foreseeable misuse and disposal, estimate the severity and probability of harm for each, and record the protective measures taken: inherently safe design, guards and protective devices, and finally warnings and instructions. Standards such as ISO 12100 for machinery safety and the risk assessment methodologies used for consumer products provide structured approaches, but the principle is universal: the file must show that someone thought systematically about what could go wrong and did something about it. For products where harmonised standards do not cover every requirement, the risk assessment is where the manufacturer justifies its own technical solutions. The assessment must be updated when the product changes or when new information emerges, such as field incidents or new scientific knowledge. A risk assessment frozen at the original design date, while the product has been through three revisions, undermines the whole file. ## Standards, testing and the state of the art The file should list every harmonised standard applied, with the exact edition and date, and note which essential requirements each covers. Where standards are applied partially, the file must explain what was omitted and how the gap was addressed. Where no harmonised standard was used, the file must describe the alternative technical solution in enough detail for an authority to follow the reasoning. Test reports need context to be useful: the standard and clause tested, the laboratory, the sample identification linking the report to the product version, the results and the conclusion. Reports on the wrong product version, or on samples that do not represent production, are a common inspection finding. Production control records, showing that manufactured units match the assessed type, complete the chain from design to market. Keeping standards current is part of file maintenance. When a cited standard is superseded, the file should record the transition: which version was used for which production dates and when the new version was adopted. This history is exactly what authorities check during inspections of long-lived products. | File element | Purpose | Common failure | |---|---|---| | Product description and drawings | Identify what was assessed | File does not match the marketed product | | Risk assessment | Show hazards were controlled | Generic template with no product specifics | | Standards list | Claim presumption of conformity | Outdated editions, partial use unexplained | | Test reports | Evidence of compliance | Wrong version, unrepresentative samples | | Declaration of conformity | Formal legal statement | Missing, unsigned or inaccurate | | Labelling and instructions | Show user information duties met | Artwork differs from shipped product | | Change records | Prove ongoing control | Design changes without re-evaluation | ## Language, format and availability Technical documentation must be drawn up in a language acceptable to the market surveillance authority that requests it, which in practice means the authority may require a translation. Many manufacturers prepare the file in English and arrange translations on request, but the declaration of conformity itself must be available in the languages of the markets where the product is sold. Format is flexible: paper or electronic files are both acceptable, provided the file is complete, organised and retrievable. Electronic document management with version control is now the norm, and it pays off during inspections when an authority asks for a specific test report or drawing. Scattered files across engineering, quality and regulatory drives, with no index, create the impression of disorganisation that invites deeper scrutiny. Availability means prompt production. Authorities typically set deadlines measured in days, not months, and importers must be able to obtain the file from the manufacturer within that window. Contracts with manufacturers should include explicit documentation handover duties and response times, because an importer that cannot produce the file is non-compliant regardless of the product's actual safety. ## Sector variations Different sectors emphasise different elements. Machinery files centre on the risk assessment per the Machinery Regulation and the technical construction file. Medical device technical documentation follows the detailed structure of the Medical Devices Regulation annexes, including clinical evaluation. Radio equipment files emphasise spectrum and EMC test reports. Construction products require the declaration of performance and assessment and verification of constancy of performance records. For RoHS, EN IEC 63000 defines a supplier-declaration-based process rather than finished-product testing, so the file is built from material declarations and risk assessments of the supply chain. For the General Product Safety Regulation, the documentation is proportionate to the product's risks but must still include the safety assessment. Understanding the sector's expectations before assembling the file avoids rebuilding it under inspection pressure. ## Maintaining the file over the product lifecycle The technical file is a living document. Design changes, new suppliers, updated standards, field incidents and new market entries each trigger a review: does the change affect compliance, and does the file reflect it? A change control process that routes every modification through a compliance check, with the outcome recorded in the file, keeps the documentation aligned with reality. At end of life, the 10-year retention clock runs from the last placing on the market, not from the first. Companies need retention policies that preserve files for discontinued products, including the systems to retrieve them, long after the engineering team has moved on. Authorities do investigate legacy products, particularly where incidents emerge years after sale. ## Frequently asked questions Who draws up the technical documentation? The manufacturer. Importers and distributors must verify it exists and ensure it can be made available, but the duty to create and maintain it sits with the manufacturer. How long must the file be kept? Generally 10 years from the date the last unit of the product was placed on the market. Sector legislation occasionally sets different periods, so check the applicable directives. Can the file be entirely electronic? Yes, provided it is complete, organised and can be produced promptly on request. Version control and an index are strongly recommended. What language must the file be in? A language acceptable to the requesting authority. Prepare the file in a widely usable language such as English and be ready to translate, while keeping the declaration of conformity in each market's language. Does a test report alone constitute technical documentation? No. Test reports are evidence within the file, but the file must also contain the product description, risk assessment, standards analysis, declaration and the other elements the legislation requires. What happens if I cannot produce the file when asked? The authority will treat the product as non-compliant with the documentation requirements, which alone can justify withdrawal measures, and will investigate the substantive compliance more deeply. ## Sources - New Legislative Framework building blocks - EU harmonised standards overview - EU market surveillance framework