MDR Annex II sets out, in six numbered sections, exactly what the technical documentation of a medical device must contain: (1) device description and specification, (2) information to be supplied by the manufacturer, (3) design and manufacturing information, (4) general safety and performance requirements, (5) benefit-risk analysis and risk management, and (6) product verification and validation. The structure is not a suggestion. It is the table of contents the auditor expects, in the order Annex II prescribes, with cross-references that work both directions. Startups that follow the Annex II structure pass audits with fewer nonconformities. Not because volume is lower, but because the auditor can find what they need.

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

TL;DR

  • MDR Article 10(4) obliges manufacturers to draw up and keep up to date technical documentation as set out in Annex II and Annex III.
  • Annex II has six sections, numbered 1 to 6, and each section has its own subsections with specific content requirements.
  • The structure is prescriptive. Reordering sections, merging them, or inventing your own chapter headings makes the file harder for the auditor to navigate. And harder to navigate means more findings.
  • Annex III (post-market surveillance technical documentation) is a separate annex but lives alongside Annex II and must cross-reference into it.
  • Tibor has watched a three-person company pass with zero nonconformities because their file followed Annex II exactly. He has also watched the opposite: a file the auditor described as a treasure hunt, where information was present but hidden.

Why Annex II structure is not optional

The instinct of many startup teams is to treat the technical file as an internal document. Organised the way the team thinks about the product. Hardware in one chapter because the hardware engineers wrote it. Software in another because the software team owns it. Risk management in a binder because the risk manager keeps it. Clinical evaluation tucked behind marketing because that is who ran the trial.

None of this is wrong from an internal perspective. All of it is wrong from an audit perspective. The auditor is not reading your file to understand how your team is organised. The auditor is reading it to verify that every obligation in Annex II has been addressed and that the evidence chain holds together. If the file is organised around your team instead of around Annex II, the auditor has to translate every question into your internal map and back again. Translation introduces friction. Friction produces nonconformities. Sometimes substantive, sometimes structural, always avoidable.

MDR Article 10(4) is the obligation:

"Manufacturers of devices other than custom-made devices shall draw up and keep up to date technical documentation for those devices. The technical documentation shall be such as to allow the conformity of the device with the requirements of this Regulation to be assessed. The technical documentation shall include the elements set out in Annexes II and III.". Regulation (EU) 2017/745, Article 10, paragraph 4.

The phrase "the elements set out in Annexes II and III" is the whole game. Annex II lists the elements. The file has to include them. The structure in Annex II is the structure the auditor will use. Follow it, and the audit becomes a conversation. Ignore it, and the audit becomes a treasure hunt.

Two files, one lesson

There is a Lower Austria company. Three people, one product, one regulatory partner, one audit. Their technical documentation followed Annex II section by section. Section 1 was the device description. Section 2 was the labelling and IFU. Section 3 was design and manufacturing. Section 4 was the GSPR checklist, cross-referenced to the evidence. Section 5 was the benefit-risk analysis and the risk management file. Section 6 was verification and validation. Every cross-reference worked. Every section could be located in under a minute. They went into their first Notified Body audit with the same dread every startup feels. They came out with zero nonconformities. A three-person team produced a cleaner file than several larger teams the same auditor had assessed that quarter.

Now the other file. A startup. Location not important. Submitted a technical file that an auditor later described as a "treasure hunt." The structure was random. The device description was partly in one chapter and partly in another. The GSPR table existed but pointed to evidence locations that did not match the actual file tree. The risk management file was a standalone binder with no connection to the design evidence. Information was present, in most cases. But the auditor had to go looking for it, and every time the auditor had to look, the clock ticked and the confidence in the file dropped. The audit produced nonconformities that were almost entirely about structure, not content. The content was there. The structure was not.

The lesson is the same one that repeats across every audit Tibor has watched. Volume is not the variable. Structure is the variable. An Annex II-shaped file of 400 pages will outperform a randomly-shaped file of 800 pages, every time, with any auditor.

The Annex II structure at a glance

Annex II is organised into six sections, each with sub-numbered requirements. The high-level map is:

  1. Device description and specification, including variants and accessories. What the device is, what it does, what is in the family.
  2. Information to be supplied by the manufacturer. Label, IFU, packaging.
  3. Design and manufacturing information. How the device is designed and made, including suppliers and subcontractors.
  4. General safety and performance requirements. The Annex I checklist, method of demonstration, and the evidence for each applicable requirement.
  5. Benefit-risk analysis and risk management. The benefit-risk determination under Annex I section 1 and 8, together with the risk management file under EN ISO 14971:2019+A11:2021.
  6. Product verification and validation. Pre-clinical and clinical data, including verification tests, biocompatibility, software verification and validation, stability, and the clinical evaluation.

Annex III covers the post-market surveillance technical documentation and sits alongside Annex II. Annex III is covered separately in the MDR Annex III post on PMS technical documentation. The two annexes are related but distinct, and conflating them is a common structural mistake.

Every one of the six Annex II sections has to be present. Every one has to be findable. Every one has to cross-reference cleanly to the others where the content overlaps. The rest of this post walks through each section in order.

Section 1. Device description and specification

Section 1 is where a stranger first meets the device. It contains the device name and trade names, the intended purpose, the intended patient population, the intended users, the indications and contraindications, the classification rule applied under Annex VIII, the novelty of the technology, variants and accessories, a general description of the key functional elements, a description of the raw materials and critical components, and technical specifications such as features, dimensions, and performance attributes.

This section carries more weight than teams expect. The intended purpose written here becomes the reference point for classification, for clinical evaluation, for labelling, and for post-market surveillance. If the intended purpose in Section 1 does not match the intended purpose on the label, in the clinical evaluation, and on the website, every downstream section has a structural problem. The mechanics of intended purpose are covered in the post on documenting intended purpose in the technical file. The short version is: write it once, carefully, and reference it from every other section.

The most common Section 1 mistake is under-specifying the device family. Startups often have variants. Different sizes, different regions, different configurations. And fold them all into one description without showing which configurations are covered by the same conformity assessment. The auditor needs to see the family tree explicitly: which variants exist, which are in scope, and how differences are handled. Hiding variants does not remove them. It just moves the conversation into the audit room.

Section 2. Information to be supplied by the manufacturer

Section 2 covers the label, the packaging, and the instructions for use. Every language version required by the Member States where the device will be made available. Every symbol referenced against the applicable harmonised standard. Every warning, contraindication, and use limitation traced to a specific risk in the risk file and a specific clinical statement in the clinical evaluation.

The cross-references matter. A warning on the label should not appear out of thin air. It should trace back to Section 5 (a hazard identified in the risk file, a control measure that requires user information) and to Section 6 (the clinical evidence that established the limitation). The auditor will pick a warning, follow the trail, and look for the whole chain. If the chain breaks, the finding is written.

The most common Section 2 mistake is label claims that exceed what the technical documentation supports. Tibor has watched companies put claims on their website or on sales materials that the technical file does not substantiate. And under the MDR definition of intended purpose, the materials are part of the intended purpose whether the team meant them to be or not. If the website says the device does X and the technical file proves it does Y, the auditor will find the gap. The fix is to bring Section 2 and the external materials into alignment before submission, not after.

Section 3. Design and manufacturing information

Section 3 describes how the device is designed and how it is manufactured, including information sufficient to allow a general understanding of the design stages and the manufacturing processes. It also identifies all sites, including suppliers and subcontractors, where design and manufacturing activities are performed.

For startups, the trap here is the supplier section. Most early teams treat suppliers as an afterthought. Contracts are informal, quality agreements are missing, critical suppliers are not flagged. Annex II Section 3 expects the supplier relationships to be mapped and controlled. The QMS under EN ISO 13485:2016+A11:2021 will be checked against this section as part of the audit; if the QMS supplier controls do not match the supplier list in Section 3, the inconsistency becomes a finding.

The other Section 3 trap is change control. Every design change that affects the device as placed on the market should be traceable through the design history and reflected in Section 3. A design change that sits only in the engineering team's internal wiki is a nonconformity waiting to be found. Tibor tells a separate story about a Graz company that changed a casing from 3D print to injection mould. Nominally a "minor" manufacturing change. And triggered a full re-run of biocompatibility testing because the material contact profile had changed. If Section 3 does not reflect the current manufacturing reality, the file is out of date the day it is submitted.

Section 4. General safety and performance requirements (GSPR)

Section 4 is the heart of the technical file from an audit perspective. It is the documented evidence that the device meets every applicable general safety and performance requirement in Annex I of the MDR.

The standard form is a GSPR checklist. A table that lists every requirement in Annex I, marks each as applicable or not applicable with justification, identifies the method of demonstration (for example, a harmonised standard, an in-house test, a literature reference), and points to the specific evidence in the rest of the technical file that demonstrates conformity. Every applicable row has to have a real, findable evidence reference. Every non-applicable row has to have a justification that holds up to scrutiny.

The mechanics of the GSPR checklist are covered in the dedicated post on documenting the GSPR with an Annex I checklist. The short version: if Section 4 is empty, incomplete, or out of sync with Sections 5 and 6, the file fails the audit regardless of how good the rest of the content is. This is the section that gets sampled hardest, because the auditor uses it as a map into the rest of the file.

The most common Section 4 mistake is marking requirements as "not applicable" without justification. "Not applicable" is a valid answer if it is justified. For example, a purely software device will not have requirements related to chemical, physical, and biological properties in the same way an implant will. "Not applicable" with no justification is just a blank. The auditor treats blanks as findings.

Section 5. Benefit-risk analysis and risk management

Section 5 contains two linked components: the benefit-risk determination required by Annex I sections 1 and 8, and the risk management file built under EN ISO 14971:2019+A11:2021.

The benefit-risk analysis is the reasoned argument that the benefits of the device outweigh the residual risks for the intended patient population and the intended purpose. It is not a single paragraph. It is a structured document that identifies the benefits (clinical, operational, economic), the residual risks after all controls have been applied, and the judgement that benefits outweigh risks. It has to be traceable to the risk management file, to the clinical evaluation in Section 6, and to the intended purpose in Section 1.

The risk management file is the ISO 14971 output: the risk management plan, the hazard analysis, the risk estimation and evaluation, the risk control measures, the residual risk evaluation, and the overall risk evaluation. Every risk has to trace forward to a control measure and backward to a hazard. Every control measure has to trace to design evidence, to labelling, or to training. And those traces have to be real, not decorative.

The most common Section 5 mistake is a risk management file that lives in isolation. The file exists, sometimes impressively, but nothing in Sections 3, 4, or 6 points to it and nothing in it points outward. The auditor asks "how did you control this specific risk in the design?" and the team has to reconstruct the link from memory. That reconstruction is the finding. The benefit-risk and risk management mechanics are covered in the dedicated post on benefit-risk analysis in the technical documentation.

Section 6. Product verification and validation

Section 6 contains the pre-clinical and clinical data that demonstrate the device performs as intended and is safe. It includes verification and validation tests (electrical safety, mechanical performance, software verification and validation, interoperability, biocompatibility, stability, sterility if applicable), the pre-clinical evaluation where applicable, and the clinical evaluation report required under MDR Article 61 and Annex XIV.

For software devices, Section 6 is also where the software verification and validation evidence built under EN 62304:2006+A1:2015 lives, together with the cybersecurity evidence under EN IEC 81001-5-1:2022 where applicable. For devices with electrical components, Section 6 includes the test reports against EN 60601-1 (with its relevant amendments) and the EMC evidence under EN 60601-1-2. For devices with patient contact, Section 6 includes the biological evaluation under EN ISO 10993-1:2025.

The mechanics are covered in the dedicated post on verification and validation evidence in the technical documentation. The structural point for this post is that Section 6 is the longest section in most files and the one where the discipline of cross-referencing matters most. Every test report should trace to a specific GSPR row in Section 4 and to a specific risk control in Section 5. Test reports that do not trace anywhere are shelfware. They add weight without adding compliance value.

How cross-references should work

Annex II is not six independent files glued together. It is one document with heavy internal cross-referencing, because the same fact appears in multiple places and must be consistent across all of them.

A working cross-reference scheme has three properties. First, it is bidirectional. If Section 4 points to a test report in Section 6, Section 6 should also know which Section 4 rows depend on it. Second, it uses stable identifiers, not page numbers or version-dependent labels. A risk ID like RISK-034 or a test ID like TR-EMC-02 stays valid across revisions. Page numbers do not. Third, it is enforced by the document control process. When a test report is updated, every reference to it is updated in the same change. This is where EN ISO 13485:2016+A11:2021 document control meets Annex II structure.

The treasure hunt file mentioned earlier failed on all three properties. References were one-directional. Identifiers were tied to page numbers that had changed between revisions. Document control had not propagated updates. The content was real work. The cross-references were not maintained. The auditor could not follow the chains, and the file was scored accordingly.

How to structure the file so an auditor can navigate it

The single most effective technique is to use the Annex II structure as the literal table of contents. Chapter 1 is Section 1, chapter 2 is Section 2, and so on through chapter 6. Sub-chapters mirror the sub-numbering of Annex II. This sounds trivial and is trivial, and it is still the most common thing startups get wrong, because the internal team's instinct is to organise the file around the team's mental model rather than the auditor's.

A second technique is the GSPR checklist as a navigation hub. If Section 4 is built as a table with working links from each row into the specific evidence in Sections 3, 5, and 6, the auditor can sample the file from Section 4 and reach any piece of evidence in seconds. The GSPR checklist is not just a compliance artifact; it is the index of the entire file.

A third technique is a single master document. Sometimes called the technical file index or the table of contents. That lists every document in the file with its identifier, version, and location, grouped by Annex II section. This document is the first thing the auditor sees and the last thing they update during the audit. A file without a master index is a file the auditor has to reconstruct on the fly. A file with a good master index is a file the auditor can trust.

Common structural mistakes

  • Reordering the sections to match the team's mental model. Hardware in the first chapter, software in the second, clinical at the end. Every deviation from Annex II's order forces the auditor to translate back and forth. Every translation produces friction.
  • Merging sections to "simplify" the file. Combining Section 4 and Section 5 because "the GSPR checklist already mentions the risks" hides Section 5 and makes the risk management file unfindable.
  • Inventing chapter headings that do not appear in Annex II. "System overview" instead of "device description." "Quality and safety" instead of "GSPR." The auditor is looking for the Annex II headings. Give them the Annex II headings.
  • Unidirectional cross-references. Section 4 points forward into Section 6 but Section 6 has no idea which Section 4 rows depend on it. When a Section 6 document changes, Section 4 goes out of date invisibly.
  • Treating Annex III as part of Annex II. The post-market surveillance technical documentation is a separate annex with its own content. Folding it into Annex II without explicit separation produces structural findings in both.
  • A table of contents that does not match the actual file tree. The index says Section 3.2.4 is at page 87. Page 87 is something else. This is the simplest structural finding to write and the most embarrassing to receive.
  • Label claims that exceed what the technical file supports. Section 2 content has to be provable by Sections 4, 5, and 6. If the website says more than the file proves, the auditor reads the website too.

The Subtract to Ship angle

Structure is where subtraction pays off most clearly. A file that follows Annex II can be smaller than a file that does not, and still pass. The startups Tibor sees producing the largest files are usually the ones who do not trust the Annex II structure. They add chapters, appendices, and summary documents to compensate for a file that does not flow. The addition does not fix the flow. It just adds weight.

The Subtract to Ship move is to start from Annex II as the skeleton, populate each section only with the content the section calls for, and refuse to add any document that does not trace to a specific Annex II requirement or to a cross-reference from another section that does. Documents that are nice to have, documents that exist to show diligence, documents that summarise other documents without adding evidence. All of these come out. What remains is a file that is shorter, tighter, and easier to audit. The full methodology is explained in the Subtract to Ship framework for MDR.

Applied to Annex II specifically: write the file the Lower Austria three-person company wrote, not the treasure hunt file. Discipline is the variable. Discipline is free.

Reality Check. Where do you stand?

  1. Does the top-level table of contents of your technical file use the six Annex II sections in order, with matching sub-numbering?
  2. Can a stranger opening the file locate the intended purpose in Section 1 within 60 seconds?
  3. Does your GSPR checklist in Section 4 point to real, stable identifiers in Sections 3, 5, and 6. And do the backward references exist?
  4. Is your risk management file integrated with Sections 3, 4, and 6, or does it live as a standalone binder?
  5. Do your label claims in Section 2 match what the evidence in Sections 4 and 6 actually proves?
  6. Does Section 3 reflect the current manufacturing reality, including every supplier and every design change made since the last revision?
  7. If an auditor asked you to trace a single Annex I requirement end to end, could you do it in under five minutes without opening more than three documents?

Frequently Asked Questions

What does MDR Annex II actually require? Annex II requires the technical documentation to include six numbered sections: device description and specification, information supplied by the manufacturer, design and manufacturing information, the general safety and performance requirements checklist with evidence, the benefit-risk analysis and risk management file, and the product verification and validation data including the clinical evaluation. The obligation to prepare and maintain this documentation is set out in MDR Article 10(4).

Do I have to follow the Annex II order exactly in my technical file? You are not legally prohibited from reordering sections, but in practice every Notified Body auditor expects the Annex II structure. Reordering makes the file harder to audit and tends to produce structural nonconformities even when the content is good. The safest and most efficient approach is to follow the Annex II numbering as the literal table of contents.

Is Annex III separate from Annex II or part of it? Annex III is a separate annex covering the post-market surveillance technical documentation. The PMS plan, PMS reports, PSURs where applicable, and trend reports. It sits alongside Annex II and cross-references into it but should be maintained as a distinct body of documentation. MDR Article 10(4) refers to both annexes together because a manufacturer's technical documentation obligation covers both.

How large should each Annex II section be? There is no required length. Section length is driven by the class and complexity of the device. For a Class I software device, Section 6 can be tens of pages. For a Class IIb active implantable or a Class III device, Section 6 can be thousands of pages. The test is not volume but completeness and traceability. Every applicable requirement addressed, every claim supported by evidence, every cross-reference working in both directions.

Can we use our internal project naming for chapters instead of the Annex II names? Tibor strongly advises against it. Auditors are trained on Annex II terminology and look for the Annex II headings when they open a file. Using internal naming adds a translation layer between the file and the audit, and every translation layer costs time and trust. Use the Annex II headings verbatim.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10(4) (obligation to prepare and keep up to date technical documentation as set out in Annexes II and III), Annex II (technical documentation, sections 1 to 6), Annex III (technical documentation on post-market surveillance), Annex I (general safety and performance requirements). 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.

This post is part of the Technical Documentation & Labeling series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. Tibor has audited technical files on both sides of the table. As a Notified Body lead auditor and as a founder assembling his own company's files. The structure described here is the structure that survives both perspectives.