---
title: Common Technical Documentation Gaps Found in Startup Audits
description: The ten most common technical documentation gaps that surface in startup MDR audits — and the Annex II section each one lives in.
authors: Tibor Zechmeister, Felix Lenhard
category: Technical Documentation & Labeling
primary_keyword: common technical documentation gaps MDR
canonical_url: https://zechmeister-solutions.com/en/blog/common-tech-doc-gaps-startup-audits
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Common Technical Documentation Gaps Found in Startup Audits

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **The ten most common technical documentation gaps in startup MDR audits are: incomplete GSPR checklists, risk files disconnected from design evidence, website claims that exceed the technical file, missing classification rationale, superficial benefit-risk analysis, incomplete software lifecycle documentation, broken verification and validation traceability, biocompatibility gaps after material or process changes, clinical evaluation disconnected from the intended purpose, and PMS plans that were never written. Each one maps to a specific section of MDR Annex II and each one is fixable if you catch it before the auditor does.**

**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 that allows the conformity of the device with the Regulation to be assessed. Annex II sets out the structure.
- The ten gaps in this post account for the large majority of technical documentation findings Tibor has seen in startup audits across hundreds of projects.
- Every gap maps to a specific Annex II section. The auditor does not look for "a tech file." The auditor walks Annex II section by section and checks whether your file answers each requirement.
- The most dangerous gaps are the invisible ones: risk files that look complete but are not connected to design evidence, and website claims that quietly exceed what the technical file supports.
- Structure beats volume. Three-person companies with disciplined tech files pass audits that 30-person companies with chaotic files fail.

---

## Why tech doc gaps matter more than any other audit category

A Notified Body auditor walking into a startup does not start with the QMS or the clinical evaluation. They start with the technical documentation, because that is the single artefact that should demonstrate — in one coherent package — that the device is safe, that it performs as intended, and that the manufacturer understands what they have built. Under MDR Article 10(4), every manufacturer is obliged to draw up and keep up to date technical documentation per Annex II and, where applicable, Annex III for post-market surveillance. Under Annex IX for most conformity assessment routes, the Notified Body assesses this file directly.

Tibor has audited startup technical files that were three binders thick and still failed, and others that were a single well-structured PDF and passed with zero non-conformities. The difference is not volume. The difference is whether the file answers the Annex II questions in the order Annex II asks them, with evidence traceable to every claim made.

One of the ugliest examples was a tech file submission where the sections were randomly ordered, cross-references pointed to documents that did not exist, and evidence for GSPR items was scattered across seven different folders with no index. The auditor called it a treasure hunt. That submission became an 18-month corrective action cycle — not because the underlying work was wrong, but because the documentation could not prove it was right.

The ten gaps below are the ones that show up most often in first-time startup audits. Each one is a specific Annex II section, a specific reason auditors find it, and a specific fix.

---

## Gap 1: GSPR checklist incomplete or "N/A" without justification

**Annex II section:** Section 4 — General Safety and Performance Requirements (the GSPR checklist).

**Why auditors find it:** Annex II Section 4 requires the technical documentation to contain the information needed to demonstrate conformity with the General Safety and Performance Requirements set out in Annex I, including a justification, validation, and verification of the solutions adopted. In practice this means a row-by-row checklist against every GSPR item, with one of three entries for each row: applicable (with the evidence reference), not applicable (with a written justification), or partially applicable (with explanation and evidence). Startups routinely mark large blocks of GSPR items as "N/A" with no justification, or worse, leave rows blank entirely. The auditor does not accept a blank or an undefended "N/A" — that is a finding every time.

**The pattern:** A founder looks at Annex I, sees a section that feels unrelated to their device (for example GSPR 17 on software if the device has no software), and writes "N/A" in the checklist without explaining why. The auditor has no way to know whether "N/A" means "we thought about this and concluded it does not apply because…" or "we did not read this section."

**The fix:** For every GSPR item, write one sentence of justification even when the item is obviously not applicable. "The device contains no software, therefore GSPR 17.1–17.4 do not apply." That one sentence converts a finding into a clean audit row. See the [GSPR checklist post](/blog/document-gspr-annex-i-checklist) for the full template.

## Gap 2: Risk management file disconnected from design evidence

**Annex II section:** Section 5 — Benefit-risk analysis and risk management, which references the risk management file required by Annex I GSPR 3 and EN ISO 14971:2019+A11:2021.

**Why auditors find it:** The risk management file exists. It has hazards, risks, controls. It looks complete at a glance. But when the auditor traces a specific risk control back to the design documentation — say, a software mitigation referenced in the risk table — the trace breaks. The design file does not mention the mitigation. The verification plan does not test it. The validation report does not confirm it. The risk file is an island.

**Why this happens so often:** Teams treat the risk file as a standalone document written by one person, often late in the process, from their understanding of the device. It never gets wired into the design documentation because the person writing it is not the person writing the design documents, and nobody owns the traceability.

**The fix:** Every risk control identified in the risk management file must have a bidirectional trace: forward into verification and validation evidence, and backward into a specific design decision or requirement. EN ISO 14971:2019+A11:2021 explicitly requires the risk management file to be maintained throughout the product lifecycle and connected to design, verification, and post-market activities. The auditor will test this by picking a risk at random and asking to see the trace in both directions. If the trace breaks, it is a finding on the risk file and a finding on the design documentation at the same time.

## Gap 3: Website and marketing claims exceed the technical documentation

**Annex II section:** Section 1.1 — Device description and specification, including intended purpose; and Section 6 — Product verification and validation. Also connects to Annex I GSPR 23 (information supplied with the device).

**Why auditors find it:** A Notified Body auditor will open your website during the audit. They will read the product page, the blog, the LinkedIn marketing posts, and the investor deck if it is public. Any claim made there that is not supported by evidence in the technical file is a finding — often a serious one, because it touches both the regulatory file and market-facing conduct.

**The pattern:** We have seen this play out more than once. The website of a Class IIa device startup claimed a diagnostic accuracy that was not in the clinical evaluation. It claimed a use case for a patient population that was not in the intended purpose. It claimed interoperability with a hospital system that had never been tested. None of the marketing claims had been checked against the technical file before they were published. All of them became audit findings. Several of them triggered a full re-review of the clinical evaluation.

**Why it is dangerous:** This gap is one of the most common triggers for competitor lawsuits as well. A competitor reading your website with a lawyer next to them can build an unfair-competition case on claims you cannot defend with evidence. The market surveillance authorities can act on the same basis. See [the post on misleading claims under MDR](/blog/misleading-claims-mdr) for the full exposure.

**The fix:** Before any marketing claim goes live, check it against the technical file. If the claim is not in the intended purpose and supported by verification, validation, or clinical evidence, it cannot appear on the website or in any promotional material. This is a one-hour monthly review, not a quarterly crisis response.

## Gap 4: Classification rationale missing or unsupported

**Annex II section:** Section 1.1(f) — the risk class of the device and the justification for the classification rule(s) applied in accordance with Annex VIII.

**Why auditors find it:** Annex II explicitly requires the technical documentation to state the class of the device and the rule(s) from Annex VIII that were used to reach that classification. Startups routinely state the class ("Class IIa") without naming the rule, or name a rule without explaining why it was the applicable rule in preference to competing rules that would push the device higher. In borderline cases — particularly for software and for devices with measuring functions — classification is arguable, and the auditor needs to see the argument.

**The fix:** Write a short classification rationale that explicitly names every potentially applicable Annex VIII rule, explains why each was considered, and justifies the final chosen rule. For software, reference MDCG 2019-11 Rev.1 (June 2025) for the qualification and classification logic. For general classification questions, reference MDCG 2021-24. The rationale should be one to three pages, not a sentence. Auditors are far more sympathetic to a well-reasoned argument for a borderline class than to a confident assertion without reasoning.

## Gap 5: Benefit-risk analysis absent or superficial

**Annex II section:** Section 5 — Benefit-risk analysis and risk management, specifically the benefit-risk determination required by Annex I GSPR 1, 2, and 8.

**Why auditors find it:** A benefit-risk analysis is not the same as a risk management file. The risk file identifies risks and documents controls. The benefit-risk analysis weighs the residual risks against the clinical benefits and concludes that the benefits outweigh the risks for the stated intended purpose. Annex I GSPR 1 requires that the known and foreseeable risks and undesirable side-effects are minimised and acceptable when weighed against the evaluated benefits to the patient. Startups often either skip the benefit-risk analysis entirely or paste a single paragraph that asserts "benefits outweigh risks" without showing the weighing.

**The fix:** The benefit-risk analysis must quantify or qualify each clinical benefit from the clinical evaluation, each residual risk from the risk management file, and explain the weighing. It is usually two to ten pages for a startup device. It must be updated whenever the risk file or the clinical evaluation is updated. See [the benefit-risk analysis post](/blog/benefit-risk-analysis-technical-documentation) for the structure.

## Gap 6: Software lifecycle documentation incomplete (EN 62304)

**Annex II section:** Section 2 — Design and manufacturing information, including software development lifecycle per Annex I GSPR 17.2 and EN 62304:2006+A1:2015.

**Why auditors find it:** For any device containing software — which, under MDR, is a growing majority of devices — Annex I GSPR 17.2 requires software to be developed and manufactured in accordance with the state of the art taking into account the principles of development lifecycle, risk management, and verification and validation. EN 62304:2006+A1:2015 defines the expected lifecycle activities and requires the manufacturer to assign a software safety class (A, B, or C) and perform the activities required for that class. Startups routinely skip the safety classification, skip the architectural design documentation, skip the unit verification records, or conflate software validation with system validation.

**The fix:** Build the software lifecycle documentation as the software is built, not after. The deliverables required by EN 62304 for each safety class are explicit. Assign the safety class early (it drives scope), maintain the software development plan, architectural design, detailed design for Class C, unit verification, integration testing, and software system testing. The auditor will sample specific software items and ask for the full chain. If the chain is incomplete at the item level, the finding applies to the whole software development lifecycle.

## Gap 7: Verification and validation traceability broken

**Annex II section:** Section 6.1 — Product verification and validation, including pre-clinical and clinical data required by Annex I GSPR.

**Why auditors find it:** Verification and validation are separate activities with separate traceability requirements. Verification confirms that the device meets its design inputs (the requirements). Validation confirms that the device meets the needs of the user and the intended use. The auditor expects a traceability matrix that links every design input to a verification test, every verification result to a pass/fail determination, every design output to a validation activity, and every validation activity to a documented outcome. In startup audits, the matrix is often partial — some requirements are tested but not traced, some tests exist without a requirement reference, some validation activities cover features that were never defined as requirements.

**The fix:** Maintain a living traceability matrix from day one. It does not need expensive tooling — a spreadsheet is acceptable for small projects. It needs every row filled in both directions and updated whenever a requirement, test, or result changes. When the matrix is clean, verification and validation audits are short. When it is broken, every finding cascades into adjacent sections.

## Gap 8: Biocompatibility evidence gap after material or process change

**Annex II section:** Section 2 — Design and manufacturing information, including biocompatibility evidence per Annex I GSPR 10 and EN ISO 10993-1:2025.

**Why auditors find it:** Biocompatibility evidence is device-specific and material-specific. A startup often generates biocompatibility data on an early prototype — say, a 3D-printed casing — and then changes the manufacturing process or the material before certification. The documentation is not updated. The auditor finds the prototype test report, sees the current production process differs, and raises a finding that the biocompatibility evidence does not cover the device as placed on the market.

**The real example:** A Graz company changed the casing of a patient-contacting device from 3D-printed to injection-moulded partway through development. The functional specification did not change. The external geometry did not change. But the material, the surface finish, and the manufacturing process all changed — and each of those can affect biocompatibility. The change triggered a full re-evaluation of the biocompatibility file under EN ISO 10993-1:2025, retesting of the skin contact endpoints, and an update to the risk management file and the design documentation. None of this had been captured in the change control record, because the team did not recognize the manufacturing change as a design change. It is. Under EN ISO 13485:2016+A11:2021, any change to design or production that affects the device must be documented, evaluated for impact, and approved through change control.

**The fix:** Any change to materials, suppliers, or manufacturing process must trigger a formal impact assessment covering biocompatibility, risk management, verification and validation, and the technical documentation itself. The impact assessment is the cheap part. Missing it and discovering the gap at audit is the expensive part.

## Gap 9: Clinical evaluation disconnected from the intended purpose

**Annex II section:** Section 6.1(c) — Clinical evaluation per Article 61 and Annex XIV; intended purpose per Section 1.1(a).

**Why auditors find it:** The clinical evaluation must demonstrate sufficient clinical evidence for the specific intended purpose stated in Annex II Section 1.1. When the intended purpose is revised — often late in development as the product-market fit sharpens — the clinical evaluation is not always updated to match. The result is a clinical evaluation that covers a slightly different device, a slightly different patient population, or a slightly different clinical claim than the device being certified.

**The fix:** Whenever the intended purpose changes — even a single word — the clinical evaluation must be reviewed for scope alignment. If the new intended purpose adds a patient population, extends a duration of use, or includes a new clinical claim, the clinical evaluation must be updated to cover the new scope. Article 61 is unambiguous: the clinical evidence must be sufficient for the intended purpose as stated. A mismatch between the intended purpose and the clinical evaluation is one of the fastest routes to a major non-conformity.

## Gap 10: PMS plan not yet written or not integrated

**Annex II / Annex III section:** The technical documentation on post-market surveillance required by MDR Annex III and referenced by Annex II. This covers the PMS plan required by Article 83–84 and the PMS report or PSUR required by Article 85–86.

**Why auditors find it:** Startups often treat post-market surveillance as "something we will build after CE marking." Under MDR Article 83(1), the manufacturer shall plan, establish, document, implement, maintain, and update a PMS system appropriate to the risk class and type of device. The PMS plan is part of the technical documentation required for conformity assessment — it must exist before CE marking, not after. Under Annex III, the technical documentation on PMS must include the PMS plan, the methodology, indicators and thresholds for benefit-risk reassessment, the tools for PMS data collection, and the link to PMCF where applicable. MDCG 2025-10 (December 2025) describes the full PMS system in current detail.

**The fix:** Write the PMS plan before the technical file is submitted, not after. It does not need to be long — a startup PMS plan can be 10 to 20 pages — but it must cover the methodology, the data sources, the review cadence, the thresholds for action, and the integration with vigilance and clinical evaluation. See [the PMS plan posts in the Post-Market Surveillance cluster](/blog/ten-most-common-mdr-non-conformities-startup-audits) for the template.

---

## The Subtract to Ship angle on tech doc gaps

Most startup tech files fail audit not because the underlying engineering is bad, but because the documentation is written as an afterthought — chaotic, duplicated, partial, and disconnected from the actual development work. The Subtract to Ship approach is to build the technical documentation as the device is built, in the Annex II structure from day one, with every evidence item filed in the section where the auditor expects to find it.

Three disciplines make the difference. First, own the Annex II table of contents as the master structure for every engineering deliverable. Second, enforce change control on every design, material, or process change, no matter how small it feels. Third, review the website and marketing claims against the technical file on a fixed cadence — monthly is enough — so that the market-facing claims and the regulatory claims never drift apart.

A three-person company with this discipline ships with zero non-conformities. A thirty-person company without it ships with thirty.

## Reality Check — Where do you stand?

1. Open your current GSPR checklist. For every row marked "N/A", is there a one-sentence justification? If not, how many rows are you fixing this week?
2. Pick a random risk control from your risk management file. Can you trace it forward to a verification test and backward to a design requirement — in under five minutes?
3. Open your live website today. Is there a single claim on the product page that is not explicitly supported by evidence in your technical file?
4. Does your technical documentation state the exact Annex VIII rule(s) applied for classification and explain why those rules were chosen over competing rules?
5. When was your benefit-risk analysis last updated? If it is older than the most recent revision of the risk management file or the clinical evaluation, it is out of date.
6. For every material and manufacturing change made in the last twelve months, was a formal impact assessment filed, covering biocompatibility, risk, verification and validation, and the technical file?
7. Does your PMS plan exist today, or is it on the "after CE marking" list? If the latter, move it to "this month."

## Frequently Asked Questions

**What is the single most common technical documentation gap in startup MDR audits?**
The incomplete GSPR checklist — specifically rows marked "N/A" without a written justification. It is the fastest finding to raise because the auditor can detect it in the first hour of the audit, and it is a finding every time regardless of whether the underlying assessment was correct.

**Does the MDR require the technical documentation to follow the exact Annex II structure?**
Yes. MDR Article 10(4) requires the documentation to be drawn up in accordance with Annex II and, where applicable, Annex III. Auditors walk the file section by section against Annex II. A file organised on any other logic is harder to audit and will typically attract more findings even if the underlying evidence is complete.

**How often are website claims really a source of audit findings?**
More often than founders expect. The auditor will check the current website during the audit. Any marketing claim that exceeds the intended purpose or the clinical evidence is a direct finding, and can also trigger wider re-review of the clinical evaluation and the risk management file.

**Can a small startup build Annex II-compliant technical documentation without expensive tooling?**
Yes. Tibor has audited three-person companies with zero non-conformities. The tooling is secondary — a well-maintained folder structure and a spreadsheet traceability matrix are sufficient for small projects. What matters is discipline, change control, and building the documentation alongside the device.

**Do manufacturing process changes really trigger biocompatibility re-testing?**
Yes, when the change affects material composition, surface properties, or contact conditions. A switch from additive manufacturing to injection moulding is a textbook example — the material may be nominally the same, but the process introduces different residues, different surface characteristics, and different cleaning requirements, all of which can affect biological safety under EN ISO 10993-1:2025.

**Does the PMS plan really need to be ready before CE marking?**
Yes. MDR Article 83(1) and Annex III make the PMS plan part of the technical documentation required for conformity assessment. A missing PMS plan at the point of Notified Body review is a non-conformity, not a post-market activity to be completed later.

## Related reading

- [The Ten Most Common MDR Non-Conformities in Startup Audits](/blog/ten-most-common-mdr-non-conformities-startup-audits) — the broader non-conformity landscape, with tech doc gaps in context.
- [How to Prepare for Your First Notified Body Audit](/blog/prepare-for-first-notified-body-audit) — the process side of audit readiness.
- [How to Respond to MDR Audit Non-Conformities](/blog/respond-to-mdr-audit-nonconformities) — what to do when a finding lands.
- [The Subtract to Ship Framework for MDR](/blog/subtract-to-ship-framework-mdr) — the methodology these fixes come from.
- [Technical Documentation Under MDR — The Complete Guide](/blog/technical-documentation-under-mdr) — the hub post for this cluster.
- [MDR Annex II Structure Explained](/blog/mdr-annex-ii-structure) — the section-by-section walk through Annex II.
- [How to Build Technical Documentation From Day One](/blog/build-technical-documentation-from-day-one) — the cadence and ownership model.
- [Documenting GSPR: The Annex I Checklist](/blog/document-gspr-annex-i-checklist) — the detailed GSPR checklist template.
- [Benefit-Risk Analysis in the Technical Documentation](/blog/benefit-risk-analysis-technical-documentation) — the structure for Gap 5.
- [Misleading Claims Under MDR](/blog/misleading-claims-mdr) — the exposure behind Gap 3.
- [Common Labeling Mistakes Startups Make Under MDR](/blog/common-labeling-mistakes-startups-mdr) — adjacent labeling gaps.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10(4) (technical documentation obligation), Article 32 (summary of safety and clinical performance), Article 61 (clinical evaluation), Articles 83–86 (post-market surveillance), Annex I (General Safety and Performance Requirements), Annex II (technical documentation), Annex III (technical documentation on post-market surveillance), Annex VIII (classification rules). Official Journal L 117, 5.5.2017.
2. MDCG 2025-10 — Guidance on post-market surveillance of medical devices and in vitro diagnostic medical devices, December 2025.
3. EN ISO 13485:2016 + A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes.
4. EN ISO 14971:2019 + A11:2021 — Medical devices — Application of risk management to medical devices.
5. EN 62304:2006 + A1:2015 — Medical device software — Software life-cycle processes.
6. EN ISO 10993-1:2025 — Biological evaluation of medical devices — Part 1: Requirements and general principles for the evaluation of biological safety within a risk management process.

---

*This post is part of the Technical Documentation & Labeling series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. Every gap in this list has been observed in real startup audits — most of them more than once.*

---

*This post is part of the [Technical Documentation & Labeling](https://zechmeister-solutions.com/en/blog/category/technical-documentation) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*