The pre-audit checklist a startup needs is not a list of nice-to-haves. It is a structured walk through every section of MDR Annex II, every Annex III post-market surveillance element, every applicable Annex I general safety and performance requirement, and every Annex I Chapter III Section 23 label and instructions-for-use item — with the cross-references between them verified before the auditor arrives. If every line in this checklist is green and every cross-reference resolves, the audit becomes a conversation. If any line is red or any reference is broken, the audit becomes a treasure hunt and the nonconformities write themselves.

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

TL;DR

  • MDR Article 10(4) requires manufacturers to draw up and keep up to date technical documentation containing the elements set out in Annexes II and III. Those two annexes are the skeleton of your audit prep.
  • Annex II has six numbered sections. Annex III has one structured post-market surveillance block. Annex I contains the general safety and performance requirements that every section of the file has to trace back to.
  • Annex I Chapter III Section 23 lists the label and instructions-for-use elements. Article 20 governs the CE marking. Both belong on the same audit-prep checklist as the technical file, because auditors read them together.
  • The purpose of the checklist is not decorative. It is to force every cross-reference to resolve before the audit: GSPR row to evidence file, risk control to verification test, intended purpose to clinical evaluation to IFU claim, label element to Section 23 subsection.
  • A three-person team with a structured checklist routinely outperforms a thirty-person team without one. Volume is not the variable. Structure is.

Why a single checklist covers both the technical file and the labels

The instinct is to keep labels and technical documentation in separate silos. The technical file sits with regulatory. The labels sit with marketing or operations. The instructions for use are a Word document someone finishes the week before submission. That separation is the single biggest source of preventable audit findings, because the auditor does not read them separately. The auditor opens Annex II Section 2 — "information to be supplied by the manufacturer" — and immediately reads it against Annex I Chapter III Section 23. If the label references a warning that is not in the risk management file, it is a finding. If the IFU claims a performance characteristic that is not in the clinical evaluation, it is a finding. If the CE mark is placed without the correct notified body identification number under Article 20, it is a finding.

The pre-audit checklist has to cover the whole surface at once: Annex II structure, Annex III post-market surveillance content, Annex I general safety and performance requirements, and Annex I Chapter III label and IFU elements, with the cross-references between them explicit and verified. That is what this post gives you.

The legal backbone is MDR Article 10(4):

"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.

Everything below hangs off that sentence.

Checklist 1: Annex II Sections 1 to 6 — the technical file

Annex II prescribes six numbered sections. Every one has to be present, in order, with the sub-elements the annex requires. Reordering or inventing your own chapter headings is the first structural mistake that produces findings. (Regulation (EU) 2017/745, Annex II.) The fuller walk-through is in MDR Annex II: The Structure of Technical Documentation Explained. What follows is the audit-prep checklist.

Annex II Section 1 — Device description and specification, including variants and accessories.

  • [ ] Product or trade name, general description, intended purpose, intended user group, and intended patient population documented in one place.
  • [ ] Qualification as a medical device justified against MDR Article 2(1).
  • [ ] Classification rationale under Annex VIII with the specific rule cited and the reasoning written out.
  • [ ] Variants, configurations, accessories, and device families listed and scoped into the file.
  • [ ] Basic UDI-DI and UDI-DI assigned and recorded.
  • [ ] Previous and similar generations of the device referenced where relevant.

Annex II Section 2 — Information to be supplied by the manufacturer.

  • [ ] Label artwork (every variant) filed in the technical documentation.
  • [ ] Instructions for use (every language version) filed.
  • [ ] Packaging artwork, including sterile barrier packaging where applicable, filed.
  • [ ] Every element present on the label cross-referenced to a subsection of Annex I Chapter III Section 23.2.
  • [ ] Every element present in the IFU cross-referenced to a subsection of Annex I Chapter III Section 23.4.

Annex II Section 3 — Design and manufacturing information.

  • [ ] Design inputs, design outputs, design review and design verification records present.
  • [ ] Design history traceable under the QMS process established against EN ISO 13485:2016+A11:2021.
  • [ ] Manufacturing process description, including process validation for processes whose output cannot be fully verified.
  • [ ] Suppliers and subcontractors of critical components or services listed with their scope.

Annex II Section 4 — General safety and performance requirements.

  • [ ] Full GSPR checklist covering every applicable requirement in Annex I.
  • [ ] Method of demonstration stated for each applicable requirement (standard, test, clinical data, rationale).
  • [ ] Reference to the exact document and page where the evidence lives.
  • [ ] Non-applicable requirements justified in writing, not just marked "N/A".

Annex II Section 5 — Benefit-risk analysis and risk management.

  • [ ] Benefit-risk determination documented against Annex I Sections 1 and 8.
  • [ ] Risk management file compiled under EN ISO 14971:2019+A11:2021 and traceable from hazard to risk control to verification of effectiveness.
  • [ ] Residual risks identified and communicated in the IFU where user action is required.

Annex II Section 6 — Product verification and validation.

  • [ ] Pre-clinical data: bench testing, biocompatibility under EN ISO 10993-1:2025 where applicable, stability, shelf life.
  • [ ] Software verification and validation under EN 62304:2006+A1:2015 for devices containing software.
  • [ ] Clinical evaluation report compiled under Annex XIV, Part A.
  • [ ] Post-market clinical follow-up plan where required.

See MDR Article 10(4) and the Technical Documentation Obligation and Annex II Section-by-Section Requirements for the detailed walk-throughs.

Checklist 2: Annex III — post-market surveillance technical documentation

Annex III is separate from Annex II but lives alongside it and must be presented as part of the same technical documentation package. (Regulation (EU) 2017/745, Annex III.) MDCG 2025-10 provides the most recent guidance on the post-market surveillance system that the Annex III documentation has to describe.

  • [ ] Post-market surveillance plan in place, specific to the device and its risk class.
  • [ ] Data sources defined: complaints, vigilance, field safety corrective actions, scientific literature, publicly available databases, similar devices, PMCF where applicable.
  • [ ] Indicators and thresholds for triggering reassessment of the benefit-risk analysis defined.
  • [ ] Link from the post-market surveillance plan into the risk management process and the clinical evaluation process explicit.
  • [ ] Periodic safety update report (PSUR) or post-market surveillance report template prepared, depending on class.
  • [ ] Process to feed post-market data back into the design and manufacturing file documented.

The deeper walk-through lives in Post-Market Surveillance Documentation Under MDR Annex III and MDCG 2025-10 Explained for Startups.

Checklist 3: Annex I — general safety and performance requirements

Annex I is the substantive heart of the MDR. Sections 1 to 9 cover general requirements; Chapter II (Sections 10 to 22) covers design and manufacturing requirements; Chapter III (Section 23) covers information supplied with the device. The GSPR checklist in Annex II Section 4 has to hit every applicable row in Annex I. (Regulation (EU) 2017/745, Annex I.)

  • [ ] Every Annex I requirement either marked applicable with evidence, or marked not applicable with a written justification.
  • [ ] Harmonised standards used for presumption of conformity listed with the exact edition (for example EN ISO 13485:2016+A11:2021, EN ISO 14971:2019+A11:2021, EN 62304:2006+A1:2015).
  • [ ] Where no harmonised standard is used, the alternative method of demonstration documented.
  • [ ] Cross-references from each GSPR row to the exact file and page where the evidence lives.
  • [ ] Chapter II design and manufacturing items (biocompatibility, infection control, construction, radiation, software, active devices, mechanical and thermal risks, protection against electrical and radiation risks) each addressed against the current applicable standard edition.

Checklist 4: Annex I Chapter III Section 23 — label and instructions for use

The label and IFU checklist is the part most startups underestimate. Annex I Chapter III Section 23 lists the legal content requirements. Article 20 governs the CE mark itself. (Regulation (EU) 2017/745, Annex I, Chapter III, Section 23, and Article 20.) The related deep dive is in The 10 Most Common Labeling Mistakes Startups Make Under MDR.

Section 23.1 — general principles.

  • [ ] Each device accompanied by the information needed to identify it and its manufacturer.
  • [ ] Safety and performance information relevant to the user supplied.
  • [ ] Symbols used taken from a recognised standard — in practice EN ISO 15223-1:2021 — and explained in the IFU where needed.
  • [ ] Format of the information appropriate to the user (lay, professional, or both).

Section 23.2 — particulars on the label.

  • [ ] Device name.
  • [ ] Manufacturer name and registered place of business.
  • [ ] Details to identify the device and the contents of the packaging.
  • [ ] UDI carrier where applicable (Articles 27 to 29).
  • [ ] Unambiguous indication of the expiry date, batch code, lot number, or serial number.
  • [ ] Special storage and handling conditions.
  • [ ] Any warnings or precautions needed.
  • [ ] Intended purpose if not obvious to the intended user.
  • [ ] Indication that the product is a medical device — the element most frequently forgotten because it is new under MDR compared to the former directive.
  • [ ] CE marking per Article 20, followed by the four-digit notified body identification number where a notified body is involved in the conformity assessment.

Section 23.3 — information on the sterile packaging.

  • [ ] For sterile devices, the indication of the sterile state and the sterilisation method.
  • [ ] Words or symbols making clear the packaging is a sterile barrier and what to do if damaged.

Section 23.4 — instructions for use.

  • [ ] Device identification and intended purpose consistent with Section 1 of the technical file.
  • [ ] Contraindications, warnings, precautions, residual risks, and undesirable side-effects — derived directly from the risk management file.
  • [ ] Performance characteristics consistent with the clinical evaluation.
  • [ ] Information needed to verify the device is correctly installed and ready to use safely.
  • [ ] Details of any preparation or handling required before use (sterilisation, assembly, calibration).
  • [ ] Information needed to avoid risks related to implantation.
  • [ ] Information on disposal and on substances or materials that could be hazardous.
  • [ ] Languages required by each target Member State per MDR Article 10(11) verified and in place.

The companion posts for this layer are Technical Documentation Under MDR and The 10 Most Common Labeling Mistakes Startups Make Under MDR.

Checklist 5: the cross-references the auditor will follow

Lines being present is not enough. Every line has to resolve to the correct target. These are the cross-references an experienced auditor walks in the first hour:

  • [ ] Intended purpose in Section 1 of the file = intended purpose on the label = intended purpose in the IFU = intended purpose in the clinical evaluation report. All four identical, word for word.
  • [ ] Classification rationale under Annex VIII = conformity assessment route taken = notified body identification number on the label (or absence of a number for self-certified Class I).
  • [ ] Every GSPR row in the Annex II Section 4 checklist = evidence file with page number = evidence file actually present at that page.
  • [ ] Every residual risk in the risk management file requiring user action = warning in the IFU.
  • [ ] Every performance claim on the label, IFU, and public marketing = data in the clinical evaluation or technical documentation that substantiates it. The website is part of this scope.
  • [ ] Every symbol on the label = entry in the IFU legend = current edition of EN ISO 15223-1:2021.
  • [ ] Every change to the device, label, or file since the last audit = change control record = impact assessment on conformity assessment.
  • [ ] UDI-DI on the label = UDI-DI in the technical file = UDI-DI submitted to Eudamed.

If any one of these cross-references does not resolve, the finding is already written. The whole point of the pre-audit checklist is to walk each one before the auditor does.

Common gaps even thorough startups miss

We see the same gaps repeatedly even in files that look complete on first pass. The full list is in Common Technical Documentation Gaps Found in Startup Audits; the short version for a pre-audit check:

  • GSPR checklist present but the evidence references point to outdated file paths after a reorganisation.
  • Risk management file and design verification records living in separate systems with no explicit trace.
  • Website claims drifted beyond the technical file — the marketing team added features in a hero section that the clinical evaluation does not support.
  • Classification rationale written as a single sentence without the Annex VIII rule cited.
  • Software verification and validation documented under EN 62304:2006+A1:2015 but no software safety classification (A, B, or C) recorded.
  • Biocompatibility data current at first submission, but a supplier or material change happened afterwards and the file was not updated.
  • Post-market surveillance plan exists as a template but has never been executed — no data collection, no review, no report.
  • Label elements present on the physical device but missing from the artwork stored in the technical file.

Each one of these is the kind of gap that turns a clean file into a stressful audit. Each one is preventable with the checklist above.

The Subtract to Ship angle — the checklist is the file, not an add-on

The founder instinct is to treat the audit-prep checklist as a separate artifact, something you build the week before the audit. The Subtract to Ship move is the opposite: the checklist is the file. You build the technical documentation and the labels from the checklist, and you use the checklist to verify the result every time anything changes. The evidence, the cross-references, the standards, and the labels are all populated into the same structure as you work. When the audit comes, the checklist already is the table of contents. There is nothing to reassemble.

This is the same move we cover in The Subtract to Ship Framework for MDR Compliance. Structure beats volume. A three-person team that derives both the file and the label from a single structured source routinely passes audits that larger teams fail, not because the smaller team has less to document but because the smaller team has fewer places for evidence and claims to drift apart.

The Lower Austria company we keep referring to — three people, one product — walked into their first notified body audit with exactly this approach. Their file was shaped by Annex II. Their labels were derived from Annex I Chapter III Section 23. Their GSPR checklist resolved to a single evidence folder. They passed with zero nonconformities. The opposite outcome, the "treasure hunt" file, produced nonconformities that were structural rather than substantive. The content was mostly there. The structure was not. Every time, the structure is the variable that matters.

Reality Check — Where do you stand?

  1. Can you open your technical file and point to Annex II Sections 1 through 6 in order, with no merging, no renaming, and no missing sections?
  2. Does your Annex III post-market surveillance documentation exist as a specific plan with data sources, thresholds, and a feedback loop into the risk and clinical evaluation files — not as a template?
  3. Is every applicable Annex I requirement covered by a GSPR row with an evidence reference that resolves to a specific file and page?
  4. Is every non-applicable Annex I requirement justified in writing, with the reasoning recorded?
  5. Does every element on your physical label map to a subsection of Annex I Chapter III Section 23.2, and every element in your IFU to a subsection of Section 23.4?
  6. Is your intended purpose identical, word for word, across the technical file, the label, the IFU, the clinical evaluation, and the public website?
  7. Does every residual risk in your risk management file that requires user action appear as a warning in the IFU, with a traceable link between the two?
  8. Can you prove in under a minute that your CE marking follows Article 20, with the correct notified body identification number (or no number) for your conformity assessment route?
  9. Has a single named reviewer signed off on every public claim against the technical file — label, IFU, website, pitch deck?
  10. If the notified body called tomorrow and asked for an unannounced audit, is there any item on this checklist you would need more than 24 hours to put in order?

Frequently Asked Questions

What is the single legal source for the content of the technical documentation? MDR Article 10(4) and Annexes II and III. Article 10(4) obliges the manufacturer to draw up and keep up to date technical documentation that includes the elements set out in those two annexes. (Regulation (EU) 2017/745, Article 10(4), Annex II, Annex III.)

Do I need to follow the Annex II section order? Yes, in practice. The regulation does not explicitly forbid reordering, but auditors expect the Annex II structure and will navigate using it. Reordering or merging sections produces structural findings even when the content is present. Follow the six numbered sections in order.

Are Annex II and Annex III two separate files? No. They are two parts of one technical documentation package. Annex II covers the device-centric documentation; Annex III covers the post-market surveillance documentation. Both live together and must cross-reference into each other.

Does the label audit happen at the same time as the technical file audit? Yes. The auditor reads Annex II Section 2 (information supplied by the manufacturer) against Annex I Chapter III Section 23 (the legal list of label and IFU content) in the same session. Labels and the technical file are not separable in audit scope.

What is the single most common structural mistake you see in startup files? A technical file organised around the team structure instead of around Annex II. Hardware in one chapter, software in another, risk in a binder, clinical tucked behind marketing. The content may be present but the auditor cannot navigate it. Structure the file around Annex II from the first draft.

How do I know my GSPR checklist is complete? Every applicable requirement in Annex I has a row. Each row has a method of demonstration (standard, test, clinical data, or written rationale) and an evidence reference that resolves to a specific document and page. Non-applicable rows have a written justification, not a blank "N/A".

Can a three-person startup actually produce an audit-ready file? Yes. We have watched it happen. Team size is not the variable that predicts audit outcome. Structure is. A three-person team with a file shaped by Annex II and a label derived from Annex I Chapter III Section 23 outperforms larger teams without that discipline. The checklist above is how you get there.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10(4), Article 20, Annex I (including Chapter III Section 23), Annex II, Annex III. 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. EN ISO 15223-1:2021, "Medical devices — Symbols to be used with medical device labels, labeling and information to be supplied — Part 1: General requirements".
  5. MDCG 2025-10, "Guidance on post-market surveillance of medical devices and in vitro diagnostic medical devices", December 2025.

This post is part of the Technical Documentation & Labeling series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The pre-audit checklist is the file. When the checklist is green and every cross-reference resolves, the audit becomes a conversation about a file that already works — which is the only kind of audit a resource-constrained startup can afford.