Technical documentation under MDR is the structured evidence file that proves your medical device meets every applicable General Safety and Performance Requirement in Annex I of Regulation (EU) 2017/745. Annex II defines what the file must contain and in what order. Annex III defines a second, linked file covering post-market surveillance. Article 10(4) makes the manufacturer legally responsible for drawing up, keeping current, and making available both files. Most startups get this wrong not because they write too little but because they write in the wrong shape — random structures, scattered cross-references, volume instead of clarity. A three-person company with disciplined documentation routinely outperforms a thirty-person company with a mountain of unstructured paper. Structure beats volume.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • Technical documentation under MDR is legally required by Article 10(4). Its contents are specified in Annex II (the main technical file) and Annex III (the post-market surveillance technical documentation). The two annexes are separate but interlinked.
  • The technical documentation is the evidence that the device conforms to the General Safety and Performance Requirements in Annex I. No conformity argument lives outside this file.
  • Annex II has seven main sections: device description and specification, information to be supplied by the manufacturer, design and manufacturing information, GSPR checklist, benefit-risk analysis and risk management, product verification and validation, and (for devices with specific requirements) additional information.
  • Annex III covers post-market surveillance documentation — the PMS plan, the PSUR or PMS report depending on class, and the PMCF documentation.
  • The number one failure mode is not missing content. It is unnavigable structure. Auditors call it a treasure hunt. A file the auditor cannot navigate is treated, in practice, as a file that does not contain the information.
  • A small team with a disciplined file built to the exact Annex II structure can pass a first audit with zero nonconformities. We have seen it. A large team with a sloppy file built by copy-paste cannot, and we have seen that too.

Two files, one lesson

There is a submission Tibor still remembers clearly. The company was not small. The technical file was not thin. By page count, it looked impressive. The structure was another story. Sections appeared in whatever order the person who wrote them had felt like that day. Cross-references pointed to documents that had been renamed. Basic information — intended purpose, classification rationale, the risk management summary — was not where you would expect it to be, and in several cases was not anywhere at all until you went digging. The auditor described the experience afterwards in exactly one phrase: a treasure hunt. Every section took longer than it should have. Every question produced a pause while the team went looking. The audit surfaced nonconformities that were not about the underlying work — the underlying work was mostly there — but about the fact that it was not findable. In the auditor's report, findability matters. If the evidence cannot be traced, the evidence might as well not exist.

Against that, a Lower Austria company. Three people. One product. Their first MDR audit was approached with the same dread every startup brings. Their technical documentation was built from day one to the Annex II table of contents. Every section lived where Annex II said it should live. Every cross-reference pointed to a live document. The GSPR checklist was complete. The risk file connected to the design control evidence. The clinical evaluation connected to the intended purpose. When the auditor picked a risk and asked to trace it, the team could do so in minutes. They came out of the first audit with zero nonconformities. Three people outperformed companies ten times their size that the same Notified Body was auditing that quarter. The only difference was documentation discipline.

These two stories are not rare. They are the pattern. We have watched dozens of versions of each. Structure, not volume, is the variable that separates a painful first audit from a clean one.

What the technical file actually is

Technical documentation under MDR is not a pile of evidence produced for the audit. It is a living file that represents, at any given moment, the complete conformity argument for the device. If someone unfamiliar with your company opened the file today, they should be able to answer three questions without asking you anything. What is the device and what is it for? Why is it safe and effective for that purpose? And how do you know?

The legal basis sits in Article 10(4) of Regulation (EU) 2017/745. Manufacturers are required to draw up and keep up to date the technical documentation for their devices, and that documentation must allow the assessment of the conformity of the device with the requirements of the Regulation. Article 10(4) refers directly to the content specified in Annex II and Annex III. Those two annexes are where the structure and the contents come from. The obligation is on the manufacturer — not the consultant, not the Notified Body, not the contract manufacturer. If you hold the legal manufacturer role, the file is yours and its correctness is yours.

The technical documentation is what the General Safety and Performance Requirements in Annex I are demonstrated against. Annex I is the list of obligations. The technical file is the proof that those obligations are met. Every item in Annex I that applies to your device has to be addressed somewhere in the file, with evidence. Items that do not apply must be justified with a reasoned explanation. "Not addressed" is not a valid state for any GSPR item.

The file is not a document. It is a controlled collection of documents that together make up the evidence. Under EN ISO 13485:2016+A11:2021, which provides the presumption of conformity for MDR QMS obligations, the documents in the file fall under your document control procedure. Each document has a version. Each version has a status. Changes are traceable. Superseded versions are retained for the legally required period. This is not administrative overhead. This is what makes the file trustworthy.

The Annex II structure — section by section

Annex II of Regulation (EU) 2017/745 specifies the structure and contents of the main technical documentation. The annex is written for the manufacturer and for the Notified Body in the same breath. Follow it as a table of contents. Do not invent your own structure. Auditors read Annex II for a living and expect your file to mirror it. Doing anything else creates friction for no benefit.

1. Device description and specification, including variants and accessories

The file opens with a description of the device. Not a marketing description — a technical one. What the device is, what it is called, what the trade name is, what the UDI-DI is (once assigned), what generation of the device this is, what variants and accessories fall within the scope of the file. The intended purpose as the manufacturer has defined it. The intended users, patient populations, indications, contraindications, warnings. The principles of operation. Materials. A classification rationale citing the specific rule from Annex VIII of the Regulation. A description of any previous generations of the device and of similar devices on the market.

This section sets the scope for everything that follows. If this section is wrong, everything downstream is wrong. The number of audits where a late-stage finding traces back to a sloppy device description is high enough that Tibor flags this section as "the one you cannot afford to write in a hurry."

2. Information to be supplied by the manufacturer — labels and instructions for use

This is the section covering what the user sees. Labels on the device and its packaging. Instructions for use in every language required by the Member States where the device will be placed on the market. Any electronic IFU documentation where eIFU is used. The section includes the physical labels, the symbols, and the full IFU text — not a reference to an external document, but the actual content controlled inside the technical file.

Startups routinely underestimate the labelling section. The claims you put on the label, on the packaging, on the website, and in the IFU are all part of the regulatory scope of the device. Claims you make outside the technical file but that describe the device in a way the file does not justify are nonconformities waiting to happen. A common source of labelling mistakes under MDR is the website-label mismatch pattern.

3. Design and manufacturing information

This section describes how the device is designed and how it is manufactured. Design stages. Design inputs and outputs. Verification and validation plans in summary. Identification of all sites — including suppliers and subcontractors — where design and manufacturing activities are performed. Manufacturing processes and their controls.

The depth here scales with risk class. A Class I device can cover this section briefly. A Class III implantable cannot. Either way, the logic is that an auditor should be able to understand how the device is produced and controlled from reading this section alone.

4. General Safety and Performance Requirements — the GSPR checklist

The heart of the file. Every applicable requirement in Annex I of the Regulation is listed, the method used to demonstrate conformity is stated, and the evidence is referenced. The evidence references point to other sections of the technical file or to external harmonised standards where applicable.

This is usually built as a table. Annex I requirement number, applicability (yes/no/NA with justification), method of conformity demonstration, reference to evidence, reference to harmonised standard used. A GSPR checklist for MDR Annex I is one of the first deliverables every startup should build, because it forces every other section of the file to stay connected to a specific obligation.

Auditors sample this table heavily. They pick three or five GSPR items and trace each one to the referenced evidence. If the chain breaks — if the table points to a document that does not exist, or to a section that does not contain what the table claims — it is a nonconformity. This is why the integrity of cross-references matters more in the GSPR checklist than anywhere else in the file.

5. Benefit-risk analysis and risk management

The benefit-risk analysis demonstrates that the benefits of the device outweigh the residual risks, for the intended purpose, in the intended user population. This is not a separate exercise from the risk management file — it depends on it — but the benefit-risk statement is itself a specific deliverable required by Annex I GSPR 1 and Annex II.

The risk management file is the output of the process described in EN ISO 14971:2019+A11:2021, the harmonised standard for application of risk management to medical devices. Hazard identification, risk estimation, risk evaluation, risk control, evaluation of overall residual risk, production and post-production information feedback. The file cross-references into the design evidence (how each control is implemented) and into the clinical evaluation (how residual risk is shown to be acceptable in the clinical context).

The common failure mode here is a risk file that exists as a standalone binder disconnected from the design. The auditor asks "how did you control this risk?" and the team cannot produce the evidence chain without reconstructing it from memory. Risk management has to be wired into the file, not parked next to it.

6. Product verification and validation

All of the test reports, engineering studies, performance evaluations, biocompatibility studies, electrical safety and EMC reports, software verification and validation records, usability engineering file, and clinical evaluation report. This section is where the majority of the raw evidence lives. Each report is version-controlled. Each report links back to a GSPR item in section 4 and, where applicable, to a risk control in section 5.

For software-containing devices, this section includes the software lifecycle documentation under EN 62304:2006+A1:2015. For devices with usability considerations, the usability engineering file under EN 62366-1:2015+A1:2020. For devices with biological contact, biological evaluation under EN ISO 10993-1:2025 within a risk management process. For medical electrical equipment, the test evidence under EN 60601-1 and its collateral standards. Every applicable standard contributes evidence into this section.

The clinical evaluation report sits here too — the output of the clinical evaluation required by MDR Article 61 and Annex XIV. The clinical evaluation traces the clinical claims in the device description to actual evidence, whether from clinical investigation, equivalence, or literature.

7. Additional information for specific device groups

Where the device falls into a group for which Annex II requires additional information — for example, devices incorporating medicinal substances, devices containing tissues or cells, or devices intended to administer medicinal products — this section provides it. For most startup devices this section is empty or brief. For the cases where it applies, it is legally mandatory.

A section-by-section walkthrough of Annex II goes deeper into each block with worked examples.

Annex III — the post-market surveillance technical documentation

Annex II is not the whole file. Regulation (EU) 2017/745 also requires a separate technical documentation on post-market surveillance, specified in Annex III. This is a distinct deliverable from the main technical file and one that a large number of startups discover late.

Annex III requires three main components. The post-market surveillance plan, which describes how the manufacturer will collect and evaluate data from the market after the device is placed on it. The post-market surveillance report (for Class I devices) or the periodic safety update report (PSUR, for Class IIa and above), which summarizes the findings and conclusions from the PMS data and updates the benefit-risk determination if needed. And the post-market clinical follow-up (PMCF) plan and evaluation report, which is the clinical component of post-market surveillance.

MDCG 2025-10 (Guidance on post-market surveillance of medical devices and in vitro diagnostic medical devices, December 2025) describes what a proportionate PMS system looks like in practice and how Annex III documentation integrates with the QMS processes for risk management, clinical evaluation, and vigilance. The PMS documentation is not a replacement for Annex II. It is a parallel file that feeds into and from the main technical documentation as real-world data flows in.

The Annex III PMS technical documentation post walks through the PMS plan, the reports, and the PMCF requirements in detail.

The point for this pillar post is that anyone who thinks "technical documentation" means only Annex II is missing half of the obligation. Article 10(4) sends you to both annexes, and a first audit will check both.

Why structure beats volume

More documentation is not more quality. The phrase is Tibor's and it is the single most useful mental model for technical documentation. The auditor who read the treasure hunt file was not complaining about a lack of content. The content was there. What was missing was the ability to find it. In auditor experience, a file of 800 well-structured pages is faster and cleaner to review than a file of 2,000 pages where every section has to be hunted down.

There are three reasons structure beats volume.

First, findability is treated as evidence. If the auditor cannot locate information within the expected section, the default interpretation is that the information is missing, and the burden shifts to you to prove otherwise during the audit. You can sometimes prove otherwise. Sometimes you cannot, because the information is actually missing and the disorganization was hiding that fact from you too. Either way, findability failures produce findings.

Second, a file an auditor can navigate is a file the team can navigate. If your own people cannot answer a direct question without paging through the binder, your processes are not real — they are a performance for the audit. The auditor notices this within the first few interviews. Disciplined file structure is a forcing function for disciplined internal work.

Third, volume introduces contradictions. Every extra paragraph is an extra opportunity for something to say the opposite of what something else says. A lean file is internally consistent almost by accident. A bloated file contradicts itself in places the author has forgotten, and those contradictions surface at the worst possible moment.

The Lower Austria three-person outcome was not magic. It was a small team that refused to produce anything that did not belong in Annex II, refused to write sections twice, and refused to defer the GSPR checklist to the end. They built the file the way the Regulation told them to build it. The file was smaller than the average. It was also complete, consistent, and findable. The auditor walked through it without friction. The result was zero findings.

The classic failure modes

Across the technical files we have reviewed in startup audits, the same handful of failure modes repeats. A detailed walkthrough of common tech doc gaps in startup audits covers each one in depth. The headline list:

  • Random structure. The file is organized by who wrote what rather than by Annex II. The auditor treasure hunt begins.
  • Broken cross-references. Documents are renamed or moved without updating the references that point to them. The GSPR checklist links to phantom files.
  • GSPR items silently skipped. Some Annex I requirements are marked "not applicable" without justification, or not addressed at all. Every Annex I item must have a reasoned status.
  • Risk file detached from design. ISO 14971 risk file exists. Design file exists. Nothing connects them. The auditor asks for the evidence chain and it cannot be produced without reconstruction.
  • Clinical evaluation disconnected from intended purpose. The clinical evaluation report evaluates something slightly different from the device description. Scope drift between sections.
  • Labels and IFU not under document control. The label version on the device is newer or older than the version in the technical file. The IFU in the file does not match the one shipped in the box.
  • No version of the file itself. The overall technical documentation has no master index, no version number, no last-updated date. The team cannot say which version of the file was submitted or which is current.
  • Marketing claims exceeding technical documentation. The website promises things the technical file does not demonstrate. Legally, marketing claims are part of the intended purpose. A mismatch here can trigger the deepest kind of finding.
  • Annex III treated as an afterthought. The PMS documentation is missing or reduced to a placeholder because the team thought "technical documentation" meant only Annex II.
  • Copy-paste from templates. The file contains boilerplate text that does not describe the actual company or the actual device. Sometimes the placeholder company name is still in place.

Every one of these is preventable. None of them is rare.

How startups can build the file right from day one

The right time to start the technical file is not the month before submission. It is the first week the project exists. A build-technical-documentation-from-day-one playbook covers the detailed approach; the principle summary fits here.

Use Annex II as the table of contents from day one. Create the section headings before you have anything to put under them. This sounds trivial. It is the single highest-leverage decision you will make on the file. Every document you subsequently produce gets filed under the right Annex II section immediately, and the section it belongs under forces you to write it in the right shape.

Set up document control under EN ISO 13485:2016+A11:2021 before the first document is written. Every document has a controlled number, a version, an owner, a review cycle. Every change goes through the change procedure. This is boring and unglamorous and saves your audit two years later.

Build the GSPR checklist in the first month, not the last. Every design decision thereafter gets traced to a GSPR item as it is made. You will not have evidence for most items yet — the cells will contain "planned" or "TBD" — but the structure forces the connection to be made in real time rather than reconstructed later.

Wire risk management into design from the first design review. The ISO 14971 risk file grows alongside the design file, not after it. Each control is added to the design as it is invented and linked into the risk file at the same time.

Separate the marketing claims from the technical claims deliberately. Everything the website, sales deck, and promotional materials say about the device is within scope. Keep a list of the claims you are making and check them against the technical file on a fixed cadence. The website claim-mismatch failure is one of the most avoidable and one of the most expensive when it shows up at audit.

Start the PMS plan for Annex III while the technical file is still in draft. It is much easier to write the PMS plan once while the design and the intended purpose are fresh than to bolt it on at the end.

Use templates as starting points only, not as deliverables. A good template gives you the structure. A bad template gives you the structure and prefabricated text that does not describe your company. The prefab text is the risk. A template pack for startup technical documentation is useful as scaffolding, provided every line is replaced with content that describes your actual device and your actual processes.

The Subtract to Ship approach

The technical file invites addition. Every concerned team member wants to add their section, their annex, their appendix, their just-in-case document. The accumulated effect is a file that is large, slow to update, and increasingly detached from the work it is supposed to describe.

Subtract to Ship for the technical file is the opposite discipline. Every document in the file must trace to a specific obligation in Annex II, Annex III, or Annex I of the Regulation. If it does not, it comes out. Not "move it to an appendix." Out. The file becomes a representation of the Regulation applied to your specific device, and nothing else.

The final test for the file is the same test the Subtract to Ship framework for MDR applies everywhere else. Walk through each document and each section and ask: what specific Annex II section, Annex III component, Annex I GSPR, or harmonised standard obligation does this document satisfy? If the answer is clear, it stays. If the answer is "we thought we should have it," it comes out.

A disciplined subtraction pass on a typical startup technical file removes 20 to 40 percent of the volume without touching a single piece of required evidence. The file becomes faster to update, easier to audit, cheaper to translate if the IFU needs localization, and less contradictory with itself. The two-phase development approach that many lean MedTech startups use relies on exactly this discipline — the file has to be light enough to evolve with the product.

Subtract to Ship is not an instruction to cut required content. It is an instruction to cut everything that is not required content. In a field where more documentation is mistaken for more quality, the discipline to cut is the differentiator.

Reality Check — Where do you stand?

  1. If someone handed you a printout of your current technical file, would the top-level table of contents match the structure of Annex II exactly, or would it match whatever structure your team invented?
  2. Could a competent outsider locate the intended purpose, classification rationale, GSPR checklist, risk management summary, and clinical evaluation report within 60 seconds each?
  3. For every item in Annex I of the Regulation, does your GSPR checklist contain either a reference to evidence or a reasoned justification for non-applicability? Any silent gaps?
  4. Are every cross-reference in your GSPR checklist and your risk file resolvable today, to a document that exists at the version cited?
  5. Do you have a separate Annex III post-market surveillance documentation, or is PMS a placeholder in the main file?
  6. Is every document in your technical file under document control per EN ISO 13485:2016+A11:2021, with version, owner, and review cycle?
  7. Do the claims on your website, sales deck, and packaging match what the technical file demonstrates? When did you last check?
  8. Could you, right now, name three documents in your file that do not trace to a specific Annex II section, Annex III component, or Annex I GSPR — and cut them?
  9. If the auditor asked a process owner to describe a section of the file without looking, could they?
  10. Is there a single person on your team whose full-time attention has been on the shape and integrity of the technical documentation from day one, or has it been assembled in parallel fragments that were supposed to come together later?

Frequently Asked Questions

What is the difference between technical documentation and a technical file under MDR? In the language of Regulation (EU) 2017/745, the legally correct term is "technical documentation." The term "technical file" is informal shorthand that most of the industry still uses. They refer to the same thing: the structured evidence file required by Article 10(4) and specified in Annex II. Annex III then adds a separate technical documentation on post-market surveillance. When an auditor asks for your technical documentation, they expect both.

Is Annex II the same as a design history file (DHF)? No. The design history file is a term from US FDA quality system requirements (21 CFR Part 820) and is focused on the design process evidence. MDR Annex II is broader — it covers the device description, labels and IFU, the design and manufacturing information, the GSPR checklist, the benefit-risk analysis, the risk management file, verification and validation, and additional information for specific device groups. A US-origin company exporting to Europe typically has to restructure its DHF content into Annex II shape. It is not a one-to-one mapping.

How long does technical documentation under MDR need to be retained? Article 10(8) of Regulation (EU) 2017/745 requires manufacturers to keep the technical documentation, the EU declaration of conformity, and copies of certificates available for the competent authorities for a period of at least 10 years after the last device has been placed on the market. For implantable devices, the period is at least 15 years. The retention clock runs on the file, not on the audit. Keep every superseded version within that window.

Who signs off on the technical documentation? The legal manufacturer is responsible per Article 10(4). Inside the company, the person required by MDR Article 15 — the person responsible for regulatory compliance (PRRC) — has specific duties including ensuring that conformity of the devices is appropriately checked before release. For startups that do not yet have an in-house PRRC, Article 15(2) allows small enterprises to have a PRRC permanently and continuously at their disposal rather than employed directly, provided the arrangement is genuinely continuous. Either way, the accountability sits with the manufacturer, not with the consultant who drafted the file.

Can a startup build the technical file without a full-time regulatory person? Yes. The Lower Austria three-person example proves it. What is not optional is discipline. The file has to be built to Annex II from day one, with real document control, with the GSPR checklist live from early in the project, and with someone — whether employee or ongoing external partner — whose continuous attention is on the shape and correctness of the file. Part-time regulatory attention produces part-time files, and part-time files produce findings.

Do I need Annex III documentation even for a Class I device? Yes. MDR Article 83 requires a proportionate post-market surveillance system for every device, regardless of class. Annex III specifies the documentation of that system. For a Class I device, the PMS report (rather than the PSUR required for higher classes) is the main periodic deliverable. The PMS plan, the PMCF considerations, and the connections to vigilance and CAPA still apply. MDCG 2025-10 describes the proportionality in practice.

What happens if the Notified Body finds gaps in the technical documentation at audit? You receive nonconformities. Depending on severity, they are categorized (typically as majors and minors in practice, according to the NB's convention). Majors must be closed before the certificate can be issued. You will receive a response window, typically 30 to 90 days, and you respond with CAPA evidence. The post on preparing for your first Notified Body audit covers the full audit mechanics.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10(4) (manufacturer obligation to draw up and keep up to date the technical documentation), Article 10(8) (retention periods), Article 15 (person responsible for regulatory compliance), Article 83 (post-market surveillance system), Annex I (General Safety and Performance Requirements), Annex II (technical documentation), Annex III (technical documentation on post-market surveillance). Official Journal L 117, 5.5.2017.
  2. EN ISO 13485:2016 + A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes.
  3. EN ISO 14971:2019 + A11:2021 — Medical devices — Application of risk management to medical devices.
  4. MDCG 2025-10 — Guidance on post-market surveillance of medical devices and in vitro diagnostic medical devices, December 2025.

This post is the pillar for the Technical Documentation & Labeling cluster in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. Tibor has reviewed technical files on both sides of the Notified Body table — as the lead auditor evaluating them and as a founder building his own. The treasure hunt and the three-person zero-nonconformity outcomes are from his own audit experience. Forty-four spoke posts link into this pillar with the detail behind every section.