---
title: Technical Documentation Templates for Startups: Where to Start
description: Templates can speed up MDR technical documentation work or sink it. Here is the right way to use them and how to avoid the Berlin template trap.
authors: Tibor Zechmeister, Felix Lenhard
category: Technical Documentation & Labeling
primary_keyword: technical documentation templates startups
canonical_url: https://zechmeister-solutions.com/en/blog/technical-documentation-templates-startups
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Technical Documentation Templates for Startups: Where to Start

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

> **Technical documentation templates can cut weeks of scaffolding work off an MDR project — or they can sink it. A template is a skeleton, not a deliverable. Used as a table of contents mirroring Annex II of Regulation (EU) 2017/745, a good template gets a startup from blank page to structured draft in days. Treated as a fill-in-the-blank shortcut, the same template turns into a compliance fiction the first Notified Body auditor will see through in minutes. The dividing line is whether every line in the template has been replaced with content that describes your actual device, your actual processes, and your actual evidence.**

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

---

## TL;DR

- MDR Article 10(4) of Regulation (EU) 2017/745 obliges the manufacturer to draw up technical documentation in accordance with Annex II. Templates do not change the obligation — they only structure the work.
- A good template is scaffolding built to the Annex II section order, with empty placeholders that force the team to write real content in the right shape.
- A bad template is prefabricated text that describes a generic device and a generic company. Used without discipline, it leaves boilerplate in the submitted file.
- The "Berlin template disaster" pattern — a startup buying an expensive template pack, swapping the logo, and submitting — has produced some of the worst first-audit outcomes we have seen.
- Templates under EN ISO 13485:2016+A11:2021 document control must be instantiated, versioned, and owned. An uncontrolled template file in a shared drive is not a document, it is a draft of a problem.

---

## A Berlin template disaster

Tibor has a story he comes back to whenever the subject of templates comes up. A Berlin startup had a promising device, a little bit of funding, and a deadline in front of them. Someone recommended a template pack — a well-known one, expensive, sold specifically for MDR startup projects. The founders bought it. They opened the files, found the placeholder `[Company Name]` in the headers, did a search-and-replace, added their logo, and treated the technical file as essentially finished. The content underneath was generic text written for a generic device. The risk file described hazards that did not apply. The intended purpose was a fill-in-the-blank sentence from the template that the team had lightly edited without checking whether it still matched the actual product. The QMS procedures described a company structure the startup did not have and a manufacturing process they did not run.

The first Notified Body contact went as badly as these stories always go. The auditor opened the risk file, recognised the template source in the first two pages, and asked a simple question: how does this specific hazard manifest in your specific device. The team could not answer. The auditor opened the intended purpose, compared it to the website, and found a mismatch the template had introduced. The auditor opened the supplier list in the design and manufacturing section and found suppliers the startup had never worked with — placeholder names the template had shipped with. The conversation ended in the way these conversations end. Months of corrective work. A significantly delayed submission. A large invoice from the consultant who had to rebuild the file from scratch. And the template pack, which had looked like a shortcut, became the most expensive mistake of the project.

Templates are not the enemy in that story. Discipline was the enemy. The same template pack, instantiated properly, would have saved the team weeks. Used as a substitute for thinking, it cost them months.

## When templates help

A template earns its place when it does three things.

The first is structural. A good MDR template mirrors the Annex II section order exactly: device description and specification, information supplied by the manufacturer, design and manufacturing information, the GSPR checklist, benefit-risk analysis and risk management, product verification and validation, and where applicable the additional information for specific device groups. If the template does this, it saves the startup from one of the most common errors — inventing a file structure that the auditor has to translate back into Annex II. The template functions as a pre-built table of contents that matches what the auditor will read against.

The second is cross-reference scaffolding. A good template sets up the GSPR checklist as a table with columns for Annex I requirement, applicability, method of demonstration, and evidence reference. It sets up the risk management file with identifiers that can be referenced from the design documents. It sets up the document index so that every entry has a version, owner, and location. The scaffolding is the hard part to build from scratch. Inheriting it saves real time.

The third is process prompting. A good template contains questions rather than answers. Instead of prefabricated text saying "The intended purpose of the device is [X]," it contains a prompt: "State the intended purpose in one sentence. The intended purpose must match the label, IFU, website claims, and clinical evaluation exactly." The prompt forces the team to think. The prefab sentence invites them not to.

When a template is built this way, even a small team can use it to produce a first draft of the technical file in weeks rather than months. The [build-technical-documentation-from-day-one playbook](/blog/build-technical-documentation-from-day-one) assumes templates of this kind are in use from Phase 2 onward.

## When templates hurt

The same template category that helps can hurt, and the failure mode is predictable. Templates hurt when they contain prefabricated content that describes a generic device, a generic company, or a generic process, and when the team treats that content as a starting point to edit lightly rather than to replace entirely.

The symptoms of a hurtful template are easy to spot in a file. Sentences that sound like no founder on the team would ever have written them. Risk entries for hazards that are physically impossible for the actual device. Supplier quality procedures that reference supplier types the startup does not use. Labelling sections that refer to symbols the product does not carry. Intended purpose statements that are slightly generic versions of what the device actually does. Every one of these is a template artefact left behind because somebody assumed "we will fix this later" and later never came.

The deeper problem is that a template loaded with prefab text creates the illusion of completeness. The file looks populated. Every section has content. The table of contents lines up. The confidence this produces is dangerous, because the team stops noticing that most of the content is not about them. By the time an auditor asks a direct question about a specific sentence, the team has forgotten which sentences they wrote and which sentences came from the template. The answers become guesses. The audit findings follow.

## How to evaluate a template before using it

Before any template enters the project, it should pass a short evaluation. The questions are simple, and most commercial templates fail at least one of them.

Does the table of contents mirror Annex II of Regulation (EU) 2017/745 exactly, section for section, sub-numbering included? If it invents its own headings, reject it.

Does the GSPR checklist list every current Annex I requirement, or does it list an outdated version from an older regulation or directive? Annex I has been restructured between the Directives and the MDR, and a template built against the old structure will be missing items.

Are the placeholder markers explicit and unmistakable? A good template uses `[PLACEHOLDER: describe your device here]` or similar markers that no team can miss. A bad template uses grey italicised text or comment bubbles that survive a careless edit.

Is the template structured around document control from the start, with every document carrying an identifier, version, owner, and review cycle as required by EN ISO 13485:2016+A11:2021? If the template assumes document control will be added later, it is missing the most important thing it should provide.

Does the template contain prefabricated risk entries, GSPR evidence references, or clinical evaluation text? If yes, treat this as a contamination risk — the prefab content must be deleted wholesale before the template is instantiated, not edited in place.

Is the template recent? Templates built before MDCG 2025-10 (Guidance on post-market surveillance of medical devices and in vitro diagnostic medical devices, December 2025) will often have stale PMS structures. Templates built against superseded standard editions will need updating.

Who wrote the template, and have they passed an actual MDR audit with a file built from it? This is the hardest question to answer and the most important. A template sold by someone who has never sat across from a Notified Body auditor is a theoretical artefact.

## The customisation discipline

The rule that separates working templates from broken ones is this. Every single line of prefabricated content in the template must be replaced with content that describes your actual device, your actual processes, your actual evidence, or it must be deliberately deleted. There is no third option. Not "tweaked." Not "adapted." Replaced or deleted.

Operationally, this looks like a line-by-line walkthrough of the instantiated template by someone who understands both the device and the Annex II requirement the line is addressing. Every placeholder marker is resolved. Every prefab sentence is either rewritten from scratch or cut. Every table entry is checked against reality. Every cross-reference points to a document that actually exists at the version cited. Nothing is carried forward on trust.

The discipline is slower than the fantasy of template use but faster than rebuilding a file after a failed first audit. The [post on common tech doc gaps in startup audits](/blog/common-tech-doc-gaps-startup-audits) catalogues the failure modes that untended templates produce at audit. The pattern repeats enough that the fastest way to spot a template-contaminated file is to open Section 1 and read the intended purpose aloud.

A short rule that has served teams well: if you cannot explain in your own words why a specific sentence in the file is there, delete the sentence and write a new one. The exercise of writing forces the understanding, which forces the file to match the device.

## What cannot be templated

Some parts of the technical file resist templating by their nature, and pretending otherwise is a source of damage.

The intended purpose cannot be templated. It is the single most leveraged sentence in the whole file, it drives classification and clinical evaluation and labelling, and it has to be written specifically for the device. A template can offer a prompt. It cannot offer a draft.

The classification rationale cannot be templated. The rule from Annex VIII that applies to your device is specific to your device, and the argument for it has to be constructed from the device's real characteristics.

The GSPR evidence references cannot be templated. The template can provide the table. The entries have to be filled from your real evidence, pointing to your real test reports. A GSPR checklist with template-derived evidence references is a fiction.

The risk management file cannot be templated beyond the process scaffold. Hazards, risk controls, residual risks, and the benefit-risk argument all depend on the device. Template hazard lists are starting prompts at best and contamination at worst.

The clinical evaluation cannot be templated. The clinical argument is specific to the intended purpose, the patient population, the state of the art, and the evidence available.

The PMS plan per Annex III cannot be templated in any meaningful way. The [post on building an Annex III PMS plan](/blog/mdr-annex-iii-pms-plan-startup) walks through what a real PMS plan looks like for a small team.

What can be templated is the scaffolding around these things — the section structure, the document control headers, the table layouts, the cross-reference format. Scaffolding is useful. Content is not.

## Common mistakes with templates

- **Buying an expensive template pack and treating it as a deliverable.** The Berlin pattern. The file ships with boilerplate that describes nothing real.
- **Using a template that invents its own file structure.** Deviating from Annex II costs more time at audit than the template saved at drafting.
- **Carrying prefab risk entries into the risk file.** Generic hazards for generic devices contaminate the risk analysis and distract from the real ones.
- **Leaving placeholder markers in the final file.** `[Company Name]` in a header, `[Insert intended purpose]` in a sentence. Embarrassing and auditable.
- **Using templates without document control.** The template file becomes shelfware in a shared drive, with no version, no owner, no review cycle. EN ISO 13485:2016+A11:2021 document control is not optional.
- **Using a template built for a different class of device.** A template built for a Class I software device cannot be retrofitted to a Class IIb active implantable without a complete rewrite.
- **Inheriting stale standard references.** Templates that cite superseded editions of harmonised standards silently age the file.
- **Treating templates as exempt from the customisation rule.** "It came from a reputable source" is not a defence at audit. Every line of the file is yours to justify.

The [template pitfalls and the Berlin case](/blog/template-pitfalls-berlin-case) goes deeper into the specific mechanics of how a prefab template contaminates each Annex II section. The [technical documentation templates to actually use](/blog/technical-documentation-templates-actually-use) post lists the scaffolding templates that survive the evaluation above.

## The Subtract to Ship angle

The [Subtract to Ship framework for MDR](/blog/subtract-to-ship-framework-mdr) says: every document in the file must trace to a specific Annex II section, Annex III component, or Annex I GSPR. Applied to templates, the discipline cuts in both directions.

On the addition side, a good template adds only what the Regulation requires. It does not add extra chapters, extra appendices, or extra review layers. It does not include "optional" sections that no article demands. It does not import boilerplate that looks like diligence but traces to nothing.

On the subtraction side, every piece of prefab content that does not describe the actual device is waste and must come out. Not "move it to an appendix." Out. The file is lighter, faster to update, and internally consistent once the template has been stripped of everything that was not written for this specific device.

The goal is not to reject templates. The goal is to use them for what they are — a scaffolding that gets the team to a real first draft faster — and to refuse to let them pretend to be more than that. The [post on QMS templates for startups](/blog/qms-templates-startups-mdr) applies the same discipline to the QMS side.

## Reality Check — Where do you stand?

1. Open your current technical file and search for `[` and `]` characters. Any placeholder markers still present?
2. Read your intended purpose aloud. Does it sound like something your team would write, or like something a template offered?
3. Pick three entries in your risk management file at random. Can the responsible engineer explain why each hazard applies to your specific device?
4. Look at your GSPR checklist. Does every evidence reference point to a document that actually exists at the version cited?
5. Does your table of contents mirror Annex II exactly, or has a template introduced section names that do not match?
6. Are any supplier names, contact details, or process descriptions in the file still from the template source?
7. Is every document in the file under document control per EN ISO 13485:2016+A11:2021, with version, owner, and review cycle?
8. Could you, right now, point to a specific prefab sentence that survived the customisation pass, and delete it?

## Frequently Asked Questions

**Should startups use MDR technical documentation templates at all?**
Yes, with discipline. A good template is a scaffolding that mirrors Annex II of Regulation (EU) 2017/745, provides the table layouts and cross-reference structure, and forces the team to write real content in the right shape. A bad template ships with prefab text that describes a generic device and invites the team to edit lightly. The deciding factor is not whether to use templates but whether every line of prefab content is replaced with content that describes the actual device before the file is submitted.

**What makes a template "Annex II compliant"?**
The template must mirror the Annex II section order and sub-numbering exactly, include every current Annex I requirement in the GSPR checklist, leave the evidence references blank for the team to fill in, and include the cross-reference infrastructure so that section 4 links into sections 3, 5, and 6 cleanly. Anything less is not Annex II compliant regardless of what the vendor calls it.

**How much does a template save versus building from scratch?**
A good template saves weeks of scaffolding work — building the section headers, the table layouts, the document control headers, the cross-reference format. A bad template costs months of rework when the first audit exposes the prefab contamination. The range is wide and the deciding variable is discipline, not the template itself.

**Can we use a template our consultant gives us?**
Only if the consultant has used it on a file that survived a Notified Body audit, and only if you apply the same customisation discipline you would to any other template. Consultant-provided templates are not exempt from the rule that every line of prefab content must be replaced with content describing your device.

**What is the single most dangerous thing a template can contain?**
A prefabricated intended purpose statement. Intended purpose drives classification, clinical evaluation, labelling, and the scope of the file. A template-derived intended purpose that the team edits lightly will produce mismatches across the whole file that the auditor will find quickly.

**Are free templates worse than paid ones?**
Not necessarily. The quality distribution is independent of price. Some expensive template packs ship with large amounts of prefab contamination. Some free templates provide clean scaffolding. Evaluate every template on the questions above rather than on the price tag.

## Related reading

- [Technical Documentation Under MDR: What It Is and Why Startups Get It Wrong](/blog/technical-documentation-under-mdr) — the pillar post for this cluster.
- [MDR Annex II: The Structure of Technical Documentation Explained](/blog/mdr-annex-ii-structure) — the structure every template must mirror.
- [How to Build Technical Documentation From Day One as a Startup](/blog/build-technical-documentation-from-day-one) — how templates fit into the two-phase development discipline.
- [Template Pitfalls and the Berlin Case](/blog/template-pitfalls-berlin-case) — the specific mechanics of prefab contamination, section by section.
- [Common Tech Doc Gaps Found in Startup Audits](/blog/common-tech-doc-gaps-startup-audits) — the pattern library that most template failures slot into.
- [How to Prepare for Your First Notified Body Audit as a Startup](/blog/prepare-for-first-notified-body-audit) — the audit a template-built file has to survive.
- [QMS Templates for Startups Under MDR](/blog/qms-templates-startups-mdr) — the QMS side of the same discipline.
- [Technical Documentation Templates to Actually Use](/blog/technical-documentation-templates-actually-use) — scaffolding templates that pass the evaluation.
- [Building a Lean QMS From Scratch for a MedTech Startup](/blog/lean-qms-from-scratch-medtech-startup) — building without over-relying on templates.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology behind the template discipline described here.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10 (general obligations of manufacturers), Article 10(4) (technical documentation in accordance with Annexes II and III), Annex I (general safety and performance requirements), Annex II (technical documentation). Official Journal L 117, 5.5.2017.
2. EN ISO 13485:2016 + A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. The harmonised standard governing document control, version management, and change control for any instantiated template.

---

*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 Berlin template disaster is from Tibor's direct experience rebuilding a contaminated technical file after a first Notified Body contact went badly. The scaffolding discipline described here is what survived when the file was rebuilt from scratch.*

---

*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).*