---
title: How to Build a Lean QMS for Your MedTech Startup Without Drowning in Paperwork
description: A lean QMS is not a stripped-down QMS. It is a QMS where every process reflects real work and nothing else. Here is how startups build one that actually runs.
authors: Tibor Zechmeister, Felix Lenhard
category: Quality Management Under MDR
primary_keyword: lean QMS MedTech startup
canonical_url: https://zechmeister-solutions.com/en/blog/build-lean-qms-mdr-startup
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# How to Build a Lean QMS for Your MedTech Startup Without Drowning in Paperwork

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

> **A lean QMS is not a stripped-down QMS. It is a quality management system where every process reflects the actual work the company does, and nothing else. You build it by starting from the reality of how your small team operates, listing your real processes, matching each clause of EN ISO 13485:2016+A11:2021 to a real process, removing what does not apply with written justification, writing short procedures that describe what people actually do, and sizing the document set to the risk class under MDR Article 10(9). A lean QMS runs before the audit, not just during it.**

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

---

## TL;DR

- MDR Article 10(9) requires the QMS to be proportionate to the risk class and type of device. This is the legal basis for "lean" — the Regulation itself says the QMS must match the device, not a template.
- Lean does not mean incomplete. Every clause of EN ISO 13485:2016+A11:2021 that applies to your device must be addressed. What changes is depth, not coverage.
- The right way to build a lean QMS is to start from the reality of the team's actual work and map the standard onto it, not to start from a template and try to retrofit the company into it.
- The wrong way — the most common way — is to buy a template, replace the placeholder company name, and call it a QMS. We have seen this produce 0.1 percent completion against real operations.
- A QMS that runs daily, even a small one, beats a QMS that looks impressive on the shelf. Discipline beats volume. A three-person company with a disciplined QMS can pass a Notified Body audit with zero non-conformities.

---

## Why this matters for your startup — two teams, two outcomes

A QA manager in Vienna joined a small MedTech startup to build their QMS from scratch. She had a framework she trusted from a previous company, but she did not paste it in. She sat down and went through every single process the framework contained, matched each one to the actual operations of the new company, removed what did not apply, and added what was missing. No overkill. Nothing missed. When the Notified Body came, the QMS was a perfect fit — lean, accurate, and genuinely in use. The company had a working quality system, not a theatre prop.

A Berlin-based company took a different path. They bought a QMS template package from a vendor. They replaced the placeholder company name with their own. They printed the manual. When we were asked to review it, we found a document set that was roughly 0.1 percent complete against their actual operations. The procedures described a company that did not exist. The forms referenced departments they did not have. The roles were written for a 50-person organisation. The founders believed they had a QMS because they had a binder. They had a binder.

These two outcomes are not about budget. The Berlin team spent more money on their template package than the Vienna QA manager spent on her entire first quarter of QMS work. The difference is method. One started from reality. The other started from a template.

This post is the method that produced the Vienna outcome, written so a founder or first-hire QA lead can apply it without drowning.

## The MDR text — what the regulation actually requires

MDR Article 10(9) of Regulation (EU) 2017/745 requires manufacturers of devices (other than investigational devices) to establish, document, implement, maintain, keep up to date, and continually improve a quality management system that ensures compliance with the Regulation in the most effective manner and in a manner that is proportionate to the risk class and the type of device.

The two words that matter most are "proportionate" and "effective."

"Proportionate" means the QMS scales with risk and device type. A Class I QMS is not a Class III QMS. A single-product startup is not a multi-site manufacturer. The Regulation does not ask every company to run the same QMS. It asks every company to run a QMS that fits.

"Effective" means the QMS actually does the work. A document set that nobody follows is not effective, no matter how comprehensive it looks. A half-page procedure that is followed every week is effective.

For devices going through a Notified Body conformity assessment route, MDR Annex IX (quality management system and assessment of technical documentation) is where the Notified Body assessment of the QMS is governed. The Notified Body audit under Annex IX will assess whether the QMS covers the required scope, whether it is implemented, and whether it actually runs. The word "implemented" matters — a binder on the shelf is not implementation.

The harmonised standard that provides presumption of conformity with the MDR QMS obligation is EN ISO 13485:2016+A11:2021. Using this standard correctly is the cleanest path to demonstrating that the QMS meets the Regulation. The standard itself allows exclusions and non-applicability, which is the legal hook for a lean QMS: you do not have to run every process the standard lists. You have to run every process that applies to your device and justify the ones you exclude.

This is the full legal basis for a lean QMS. It is not a loophole. It is what the Regulation and the standard say, read correctly.

## What this means in practice — lean is reality-matched, not stripped

Lean does not mean missing clauses. Lean does not mean a smaller binder. Lean does not mean cutting corners. Lean means the QMS describes the work the company actually does, the processes the company actually runs, and the controls the company actually needs for its specific device and risk class.

A lean QMS for a three-person startup building a Class I software device looks different from a lean QMS for a 20-person startup building a Class IIb active implantable. Both are lean. Both are compliant. Both match reality.

The rest of this post is the seven-step procedure for building a lean QMS that matches reality. It is HowTo content because "how" is exactly the question founders ask and rarely get a specific answer to.

## Step 1 — Start from reality, not templates

Do not open a template first. Open a blank page first.

Templates are not evil. A good framework from a previous project, or a reputable reference QMS, is a reasonable starting scaffold — but only after you know what your company actually does. The Vienna QA manager had a framework from a previous company. She did not paste it in. She used it as a reference map while walking through the real operations of the new company.

The order matters. Reality first, scaffold second. The inverse order — scaffold first, reality later — is how you end up with the Berlin binder.

Concretely, Step 1 produces nothing on paper yet. It produces a mental model. You sit with the founders and the first hires and you answer a set of questions out loud: What does this company actually do? Who designs the device? Who tests it? Who talks to suppliers? Who talks to customers? Who handles complaints? Who releases software? Who signs off on a change? What meetings already exist? What files already exist? What decisions have already been made and written down?

You leave Step 1 with a clear picture of how the company runs today, unfiltered by any standard. That picture is the foundation.

## Step 2 — List your actual processes

Now put the picture on paper. Write down every process that actually happens in the company. Not the processes you imagine a "real" MedTech company has. The ones your team performs every week.

A typical early-stage startup list looks something like this: product requirements capture, design and development, software build and release, document storage and version control, supplier selection and purchasing, complaint intake, change requests, hiring, onboarding, training, team meetings, design reviews, bug tracking, incident handling. Some of these will match ISO 13485 clauses neatly. Some will not. That is fine for now. The goal is honesty, not compliance.

Write each process as a short sentence: "We do X, with these people, using these tools, producing these outputs, on this cadence." No more than two or three sentences per process. If you cannot describe a process in three sentences, it is either not really happening or it is two processes you have been treating as one.

The output of Step 2 is a list. Ten to thirty items is typical for a small startup. This list is the reality baseline against which the standard will be mapped.

## Step 3 — Match each ISO 13485 clause to a real process

Now open EN ISO 13485:2016+A11:2021 and go clause by clause. For each clause, ask: does this describe something we already do, or something we need to start doing, or something that does not apply to us?

This is the slowest step. It is also the most important. Do not skip clauses. Do not assume. Read each one and compare it against the list from Step 2.

For each clause, record one of four outcomes.

**Outcome A — Already done.** The clause describes something the company already does. You do not need a new process. You need a short written description of what already happens, plus any missing records. This is the happy case.

**Outcome B — Partially done.** The clause describes something the company does informally or inconsistently. You need to formalise it — write down who does it, when, with what inputs and outputs, and how the evidence is captured.

**Outcome C — Not yet done, but needed.** The clause describes something the company does not do but must, given the device and risk class. Add the process. Start doing it. Record that it started.

**Outcome D — Does not apply.** The clause describes something that does not apply to this company's device or operations. Common examples: sterile production for a non-sterile device, installation activities for a device that does not require installation, servicing activities for a device the manufacturer does not service. This outcome is legitimate — the standard allows non-applicability — but it must be documented with justification (Step 4).

Work through every clause. Do not stop until every clause of the standard has landed in one of A, B, C, or D.

## Step 4 — Remove what does not apply, with written justification

Every clause you marked "does not apply" in Step 3 must be justified in writing. The Notified Body will ask. EN ISO 13485:2016+A11:2021 allows exclusions, and it requires justification for them. No justification, no exclusion.

A justification is one or two sentences: "Section X.Y.Z does not apply because this company does not perform [activity], because the device [specific reason]." Concrete. Defensible. Traceable to the device and the operations.

Examples of legitimate exclusions for a small SaMD startup: sterile packaging (device is pure software), installation (device is a web application with no on-site installation), servicing (no field service performed by the manufacturer), implant card obligations (device is not implantable).

Examples of exclusions that will not survive audit: "We are small, so we skip this." "We do not have the resources." "Our product does not need it" without specifics. The justification has to be about the device and operations, not about the company's convenience.

The output of Step 4 is an exclusions list with justifications. This list becomes part of the QMS documentation and is one of the first things an auditor reads.

## Step 5 — Write short procedures that match actual work

Now write the procedures for the processes that remained after Steps 3 and 4. Short procedures. Procedures that describe what actually happens.

"Short" means as short as possible while still answering the questions an auditor will ask: Who does this? When? With what inputs? Producing what outputs? Against what criteria? Recorded where?

A one-page procedure that describes real work beats a ten-page procedure that describes ideal work nobody follows. More documentation is not more quality. The standard asks for documented processes, not for long ones.

Write each procedure in the voice of the people who do the work. If the software release process is really "the lead developer runs the release checklist, two team members review, the release is tagged in the repository and logged in the release record" — write that. Do not translate it into the passive bureaucratic voice that makes procedures unreadable and unused.

Every procedure should pass three tests before it is finalised. First, can the person who actually does the work read it and agree it describes their work? Second, can a new hire read it and know what to do? Third, does it produce the records the standard asks for?

The third test is where most startups slip. A procedure that runs but does not generate records is invisible to an auditor. A procedure that generates records but nobody follows is theatre. A procedure that runs AND generates records is the target.

## Step 6 — Connect documents to the risk class under Article 10(9)

Now look at the document set as a whole and ask: is this proportionate to the risk class and type of device?

MDR Article 10(9) uses "proportionate" deliberately. The QMS depth, the number of controls, the frequency of reviews, the amount of evidence retained — all scale with the risk class and with the device type.

For a Class I device with no measurement function and no sterile packaging, the QMS can be genuinely small. The core processes still exist — design control, document control, CAPA, internal audit, management review, complaint handling, PMS — but each can be run by a small team with a small document set. One person may own multiple processes. Meetings that already happen can double as management reviews with minor tweaks to the agenda and minutes.

For a Class IIa device, the depth increases. More verification and validation evidence. Tighter change control. More formal clinical evaluation input into the QMS. A dedicated risk management process with traceable links into design.

For a Class IIb or Class III device, the QMS must carry substantially more weight because the Regulation and the standards demand it. There is still no excuse for bloat, but the legitimate floor is higher.

Step 6 is where you walk through the document set and remove anything that belongs to a higher class than you actually are. Over-scoped procedures. Review layers the Regulation does not require for your class. Record retention beyond what applies. Controls that exist because a template assumed a larger organisation.

At the same time, Step 6 is where you add anything you have under-scoped. If you are Class IIa and running a Class I QMS, you will fail audit. Proportionate cuts both ways.

## Step 7 — Run the QMS before the audit

This is the step most startups skip, and it is the one that decides whether the audit passes.

Before the Notified Body ever walks into the office, the QMS has to run for long enough to generate real records. Design reviews that actually happened. CAPAs that were actually opened and closed. Internal audits that were actually performed. Management reviews that actually occurred with minutes. Supplier evaluations that were actually recorded. Training that was actually delivered and documented.

Auditors read records. A QMS with pristine procedures and empty record folders is immediately suspicious. A QMS with well-worn records and a few messy human mistakes is immediately credible.

A three-person company in Lower Austria that we worked with passed a Notified Body audit with zero non-conformities. Three people. No big QA team. No expensive consulting army. What they had was discipline: every process in the QMS ran on its stated cadence, every record was produced on time, every small non-conformity they caught internally was logged and closed before the external audit. Small team, real discipline, real records. The auditor saw a company that was genuinely running its QMS, not a company that had built a QMS for the audit.

Start running the QMS as early as possible. Even a partial QMS running for six months generates more credible evidence than a complete QMS running for six weeks. Get the clock ticking. Make real mistakes in small ways, catch them in the CAPA process, and leave the evidence trail behind. That is what a lean QMS looks like when it works.

## The Subtract to Ship angle

A lean QMS is the QMS equivalent of [the Subtract to Ship framework](/blog/subtract-to-ship-framework-mdr). The same discipline applies: every process, every procedure, every document, every record has to trace back to a specific obligation — a clause of EN ISO 13485:2016+A11:2021 that applies to your device, or a specific article or annex of the MDR. If it cannot, it comes out.

The Subtract to Ship test at the end of QMS build is the same as the test at the end of a technical file build. Walk through every document in the QMS. For each one, ask: what clause of the standard or what article of the Regulation does this satisfy? If the answer is specific, keep the document. If the answer is "audit best practice" or "the template had it" or "it looks professional," cut it.

The result is a QMS that is the size it needs to be — and no larger. A QMS that runs because it is small enough to run. A QMS that survives audit because every piece of it has a reason to exist.

This is also the time axis of the [two-phase development approach](/blog/two-phase-development-approach). Phase 1 does not need a full QMS. Phase 2 does. Building the full lean QMS at the start of Phase 2 — not before, not after — is the right sequence.

## Reality Check — Where do you stand?

1. Can you describe, in one paragraph, the actual day-to-day work of your company without referring to any template or standard?
2. If you already have a QMS draft, was it built by matching a template to your reality, or by writing down your reality first and then mapping the standard onto it?
3. For every clause of EN ISO 13485:2016+A11:2021 you have excluded, can you point to a written justification tied to your device and operations?
4. Do your procedures describe what your team actually does, or what a template thought a MedTech company should do?
5. When was the last time one of your QMS processes produced a real record — not a template record, a real one with real content?
6. If a Notified Body auditor walked in next week, would they see a QMS that has been running, or a QMS that was assembled for them?
7. Is the size of your current document set proportionate to your device's risk class, or did it grow to match a template or a consultant's comfort zone?

## Frequently Asked Questions

**What is the minimum QMS for a MedTech startup under MDR?**
There is no universal minimum, because MDR Article 10(9) makes the required QMS depend on the risk class and type of device. The minimum is whatever covers every applicable clause of EN ISO 13485:2016+A11:2021 at a depth proportionate to the risk. For a Class I software device with a three-person team, this can be a small, focused document set run by a few people. For a Class IIb active device, the floor is much higher. The minimum is defined by the Regulation and the standard, not by the company's preference.

**Can I use a template QMS and edit it down?**
You can, but you should not start there. The Berlin pattern — buying a template and replacing the company name — produces a QMS that describes a company that does not exist. If you must use a template, use it only as a reference after you have written down your real processes from scratch. Then match the template against your reality, delete anything that does not apply to you, and rewrite anything that does apply in your own words.

**How many documents does a lean Class I QMS need?**
Fewer than most consultants will tell you, and more than founders hope. A reasonable Class I software startup QMS typically has one quality manual, ten to twenty procedures covering the core ISO 13485 processes that apply, a handful of work instructions for the specific technical activities, and the record templates needed to produce evidence for each procedure. The exact number depends on the device. The test is never "how many" — it is whether every document traces to a clause that applies and is actually used.

**What does "proportionate" mean under MDR Article 10(9)?**
Proportionate means the QMS matches the risk class and the type of device. Higher risk class, deeper controls. Complex device type, more specialised processes. Simple device type, simpler QMS. The word "proportionate" is a deliberate rejection of one-size-fits-all QMS templates. The Regulation says the QMS must fit the device, and the fit is the founder's responsibility to document and defend.

**Do I need a full-time QA manager to build a lean QMS?**
Not necessarily, but you need someone with genuine QMS competence running the build — whether that is a first QA hire, a fractional QA lead, or an external regulatory partner working closely with the founders. What you cannot do is hand the QMS to a template vendor and expect a QMS to come out. The competence has to live inside the company, either as an employee or as a sparring partner with enough depth to do the reality-matching work described in Steps 1 through 7.

**Is a lean QMS accepted by Notified Bodies?**
Yes. Notified Bodies assess whether the QMS meets the Regulation and the standard. A lean QMS that covers every applicable clause, is implemented, is running, and produces real records will pass audit. A bloated QMS that looks impressive but is not implemented will fail. Notified Body auditors read records and watch the system in action. They reward reality. The three-person company in Lower Austria with zero non-conformities is not an anomaly — it is the predictable result of a disciplined lean QMS.

## Related reading

- [What Is a Quality Management System for Medical Devices?](/blog/what-is-quality-management-system-medical-devices) — the hub post for the QMS cluster.
- [MDR Article 10(9) and Annex IX: The QMS Requirements](/blog/mdr-article-10-9-annex-ix-qms-requirements) — the legal basis in detail.
- [The Minimum Viable QMS for Early-Stage MedTech](/blog/minimum-viable-qms) — the companion post on the smallest legitimate QMS footprint.
- [The QMS Process Approach for Startups](/blog/qms-process-approach-startups) — how to think in processes instead of documents.
- [Document Control for Early-Stage MedTech](/blog/document-control-startup) — the specific procedure most startups underbuild.
- [CAPA Under MDR and ISO 13485](/blog/capa-mdr-iso-13485) — corrective and preventive action without bureaucracy.
- [CAPA Without Bureaucratic Overhead](/blog/capa-without-bureaucratic-overhead) — keeping CAPA lean and real.
- [Internal Audits for Small MedTech Teams](/blog/internal-audits-startup) — running internal audits when the team is tiny.
- [Common QMS Audit Non-Conformities](/blog/common-qms-audit-nonconformities) — what auditors actually find, and how a lean QMS avoids them.
- [The Subtract to Ship Framework for MDR](/blog/subtract-to-ship-framework-mdr) — the overarching methodology behind the lean QMS approach.
- [The Two-Phase Development Approach](/blog/two-phase-development-approach) — when in the timeline the lean QMS should be built.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10(9) (quality management system requirement, proportionate to risk class and type of device) and Annex IX (quality management system and assessment of 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.

---

*This post is part of the Quality Management Under MDR series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. If you are building a QMS from scratch and want a second pair of eyes to make sure your document set actually matches your reality and your risk class, Zechmeister Strategic Solutions works with founders on exactly that kind of reality-matched QMS build.*

---

*This post is part of the [Quality Management Under MDR](https://zechmeister-solutions.com/en/blog/category/quality-management) 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).*