What Is a Technical File Under ISO 13485?

What Is a Technical File and Why Does It Matter?

If you are working towards ISO 13485 certification or supplying medical devices into regulated markets, you will hear the term “technical file” mentioned constantly. Yet many manufacturers, especially those going through the process for the first time, are unclear about what it actually contains, who needs one, and how it connects to their quality management system.

A technical file is a structured collection of documents that demonstrates your medical device is safe, performs as intended, and meets all applicable regulatory requirements. It is not a single document. It is a compilation of design records, risk management outputs, testing results, labelling, and post-market data, all organised in a way that a regulator or auditor can review and follow logically.

Under ISO 13485:2016, the standard for quality management systems in the medical device industry, maintaining a technical file is not optional. It is a core requirement tied directly to design and development controls, risk management, and product realisation. If your file is incomplete, disorganised, or out of date, you are exposed, both in terms of certification and regulatory approval.

This article explains what a technical file must contain, how it differs from a Device History File and a Design History File, common mistakes manufacturers make, and how to build one that holds up under audit scrutiny.

ISO 13485 and the Regulatory Context

ISO 13485 is the internationally recognised quality management standard specifically written for organisations involved in the design, production, installation, and servicing of medical devices. It aligns with, and in many jurisdictions supports, regulatory submissions to bodies such as the Therapeutic Goods Administration (TGA) in Australia, the FDA in the United States, and the notified bodies operating under the EU Medical Device Regulation (MDR).

The standard itself does not use the phrase “technical file” as a defined term in the same way the EU MDR does. What ISO 13485 does require, across several clauses, is that you maintain documented information that collectively forms what most people refer to as a technical file. Clause 7.3 on design and development, Clause 7.5 on production and service provision, and Clause 8.3 on control of nonconforming product all contribute to the content you would expect to find in a well-structured technical file.

In practical terms, if you are seeking ISO 13485 certification and also need regulatory approval in a specific market, your technical file serves both purposes. Auditors from your certification body will want to see evidence of design controls and risk management. Regulators will want to see proof of safety and performance. A well-built technical file satisfies both audiences.

What a Technical File Must Contain

The exact contents of a technical file vary depending on the device classification, the markets you are targeting, and any applicable regulatory requirements. That said, there is a core set of content that virtually every technical file for a medical device must include.

Device Description and Intended Use

This section explains what the device is, what it is designed to do, and who it is intended for. It should cover the device name, model numbers, variants, intended patient population, intended user, and the clinical or therapeutic purpose. This is often the first section a regulator or auditor reads, so it needs to be clear and precise. Vague language here creates problems throughout the rest of the file.

Design and Development Documentation

Under Clause 7.3 of ISO 13485, you are required to plan and control the design and development of your device. Your technical file must include the design inputs, design outputs, design reviews, design verification activities, and design validation results. Each stage should be traceable to the others, meaning an auditor can follow the logic from initial requirements through to final validated product.

Design inputs are the requirements your device must meet, including functional, performance, safety, and regulatory requirements. Design outputs are the drawings, specifications, and procedures that define the finished device. Verification confirms that outputs meet inputs. Validation confirms the device actually works as intended in real use conditions.

Risk Management File

This is one of the most important components. ISO 13485 requires you to apply a risk management process throughout the product lifecycle, typically in accordance with ISO 14971, the standard for risk management of medical devices. Your technical file must reference or include the risk management file, which covers hazard identification, risk estimation, risk evaluation, risk control measures, and the residual risk assessment.

If your risk management file is thin, generic, or clearly copy-pasted from another product, auditors will notice. Risk management needs to be specific to your device, your intended use, and your foreseeable misuse scenarios.

Manufacturing Information

This section covers how the device is actually made. It includes manufacturing processes, process validations, quality control steps, and any critical suppliers or outsourced processes. If your device involves sterilisation, biocompatibility testing, or specialised assembly, that information belongs here. Clause 7.5 of ISO 13485 deals with production and service provision, and the technical file should demonstrate that your manufacturing processes are controlled and validated where required.

Labelling and Instructions for Use

All labelling, including the device label, packaging, and instructions for use (IFU), must be included. These documents need to comply with applicable regulatory requirements for the markets you are selling into. In Australia, for example, TGA has specific requirements for what information must appear on device labels and in the IFU. Your technical file should include the final approved versions of all labelling materials.

Clinical Evaluation or Performance Data

You need to demonstrate that your device is clinically safe and performs as claimed. Depending on the device classification, this might involve a clinical investigation, a literature review of equivalent devices, or post-market clinical follow-up data. For higher-risk devices, the clinical evidence requirements are more demanding. This section of the technical file must show that the benefits of your device outweigh the risks for the intended use.

Post-Market Surveillance Data

A technical file is not a static document created once and filed away. It must be kept current, and that means incorporating post-market surveillance data. This includes complaint records, adverse event reports, trend analysis, and any corrective actions taken in response to real-world performance issues. Clause 8.2 of ISO 13485 addresses monitoring and measurement, and the post-market data in your technical file demonstrates that you are actively monitoring your device once it is on the market.

Technical File vs Design History File vs Device History Record

These three terms cause significant confusion, particularly for manufacturers dealing with multiple regulatory frameworks simultaneously. Understanding the difference is important.

A Technical File is primarily a regulatory concept, most commonly associated with the EU MDR and similar frameworks. It is a compilation of documents demonstrating conformity of a device with applicable requirements. It is product-specific and contains both design and manufacturing information.

A Design History File (DHF) is a concept from the US FDA's 21 CFR Part 820 Quality System Regulation. It is a compilation of records that describes the design history of a finished device. The DHF focuses on the design and development process and is roughly equivalent to the design and development documentation within a technical file.

A Device History Record (DHR) is also an FDA concept. It contains records demonstrating that the device was manufactured in accordance with the Device Master Record (DMR). It is batch or unit specific, not design specific.

Under ISO 13485, the standard does not mandate these exact terms but does require the documented information that these records contain. If you are building a quality management system to ISO 13485 and also need to comply with FDA requirements, you will often end up maintaining documentation that satisfies both frameworks, just named differently depending on which regulator is reviewing it.

How a Technical File Connects to Your ISO 13485 QMS

The technical file does not sit outside your quality management system. It is a product of it. Every process you run under your QMS, from design controls to supplier management to complaint handling, generates records that feed into the technical file.

This is why controlled document management is so critical for medical device manufacturers. If your procedures for managing documents and records are weak, your technical file will reflect that. Version control failures, missing approval signatures, and outdated specifications are among the most common findings during ISO 13485 audits.

Similarly, your internal audit programme should periodically assess whether the technical file for each product is complete, current, and consistent with what is actually being manufactured. Many organisations treat the technical file as something that gets built for initial regulatory submission and then forgotten. That approach creates serious risk as the product evolves through design changes, manufacturing updates, and post-market feedback.

Common Mistakes Manufacturers Make With Technical Files

Treating It as a One-Time Exercise

The most common mistake is building a technical file to get through an initial submission or audit and then failing to keep it updated. Every design change, process change, or significant post-market event that affects the device should trigger a review and update of the relevant sections of the technical file. If your file describes a version of the device that no longer exists, you have a serious compliance problem.

Inadequate Traceability

Auditors and regulators want to be able to trace a claim in your technical file back to the evidence that supports it. If your risk management file references a hazard but there is no corresponding verification record showing the control measure was tested, that is a gap. Every claim needs to be supported by objective evidence, and that evidence needs to be findable.

Generic Risk Management

Risk management files that are clearly templated and not specific to the actual device are a red flag. The risk analysis must reflect the specific hazards associated with your device, your intended use, and your user population. A generic list of hazards copied from another product file will not satisfy an experienced auditor.

Missing or Outdated Clinical Evidence

Clinical evaluation is an area where many manufacturers fall short, particularly for devices that have been on the market for some time. The clinical evidence in your technical file must be current. Literature reviews need to be periodically updated, and post-market clinical follow-up data needs to be incorporated.

Poor Document Control

Technical files often contain documents from multiple authors, departments, and time periods. Without strong document control, you end up with inconsistencies, superseded versions sitting alongside current ones, and documents that reference other documents that no longer exist. This is precisely why biological evaluation and other specialised test reports within the file need to be version-controlled and linked to specific product versions.

Building a Technical File That Holds Up Under Audit

If you are starting from scratch or trying to bring an existing technical file up to standard, here is a practical approach.

Start with a document map. Before you create or gather any documents, define the structure of your technical file and list every section that needs to be populated. This map becomes your checklist and your gap analysis tool. For each section, identify what documents exist, what is missing, and what needs to be updated.

Assign ownership. Each section of the technical file should have a named owner who is responsible for keeping it current. Design and development sections typically sit with your R and D or engineering team. Risk management might be owned by your quality team. Post-market surveillance data is often managed by regulatory affairs or quality. Without clear ownership, updates fall through the cracks.

Build in review triggers. Define the events that require a technical file review. These should include design changes, manufacturing process changes, supplier changes, significant complaints or adverse events, and periodic scheduled reviews. Embed these triggers into your change control and corrective action processes.

Cross-reference everything. Where one document references another, make sure the reference is specific, including the document number and version. This makes it far easier to maintain consistency as documents are updated over time.

Test it before the audit. Before your ISO 13485 certification audit, have someone who was not involved in building the file try to answer a set of questions about the device using only the technical file. Can they find the intended use? Can they trace a risk to its control measure? Can they find the validation evidence for a critical process? If they struggle, an auditor will too. This kind of internal review is part of what good internal auditing practice looks like in a medical device context.

Working With Consultants on Technical File Development

Many small and medium-sized medical device manufacturers work with external consultants to build or improve their technical files. This can be a smart investment, particularly if you are entering a new regulatory market or dealing with a complex device classification. However, the quality of consultant support in this space varies considerably.

When evaluating a consultant for ISO 13485 or technical file work, look for someone with hands-on experience in your device category, not just general quality management experience. Medical device regulatory work is highly specialised. A consultant who has worked extensively with Class II active devices will bring different knowledge to the table than one who has mostly worked with Class I non-sterile products.

Also be clear about what the consultant will deliver. Some will build the entire technical file structure and populate it with your input. Others will review and gap-assess an existing file. Make sure the scope is agreed upfront and that the deliverables are specific. If you are comparing quotes from multiple consultants, understanding what each quote actually covers is essential before you commit.

If you need help finding qualified ISO 13485 consultants or accredited certification bodies with medical device experience, CertBetter can connect you with up to three verified providers through a single enquiry. The service is free for businesses, and every provider on the platform has been vetted for credentials and experience.