--- title: Transitioning from Startup Chaos to a Compliant QMS: The Phased Approach description: Most MedTech startups have years of chaos before they need a QMS. Here is the phased approach that converts the mess into compliance without starting from zero. authors: Tibor Zechmeister, Felix Lenhard category: Quality Management Under MDR primary_keyword: startup chaos to compliant QMS canonical_url: https://zechmeister-solutions.com/en/blog/startup-chaos-to-compliant-qms source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # Transitioning from Startup Chaos to a Compliant QMS: The Phased Approach *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **You do not build a compliant QMS by erasing two years of startup work and starting over. You build it by inventorying what already exists, mapping the real processes and records onto the clauses of EN ISO 13485:2016+A11:2021, closing the gaps against MDR Article 10(9), and running the system long enough before the Annex IX audit to generate genuine evidence. The phased approach is inventory first, minimum viable QMS build second, audit readiness third. Chaos is not the enemy. Pretending the chaos never happened is.** **By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.** --- ## TL;DR - Most MedTech startups spend eighteen months to three years in unstructured product work before they formally need a QMS. That period is not wasted — it is raw material. - MDR Article 10(9) requires the QMS to be proportionate to the risk class and type of device. It does not require the QMS to have existed since the company's first day. - The phased approach has three stages: Phase 1 inventory (what already exists), Phase 2 minimum viable QMS build (write down real processes, close the gaps), Phase 3 audit readiness (run the system long enough to produce real records). - The Annex IX assessment route tests whether the QMS is implemented and running, not whether it was built yesterday or eighteen months ago. Implementation is what matters. - The single most dangerous move in this transition is throwing away the evidence the chaotic phase produced. Design notes, emails, commit history, supplier correspondence, meeting minutes — all of this can be converted into legitimate QMS records if it is honest and traceable. --- ## The chaos starting point — what your company actually looks like today Most MedTech startups do not arrive at the QMS conversation with a blank page. They arrive with two years of Slack messages, a GitHub repo full of commits, a Google Drive with version-numbered specification documents, a Jira board with bug tickets, a folder of supplier emails, a stack of whiteboard photos from design sessions, a handful of pitch decks that describe the product in different ways, and a small pile of decisions that were made quickly and never formally recorded. That is not failure. That is early-stage product work. Every company we have worked with has looked like this when the regulatory conversation becomes serious. The founders built something, they iterated, they learned, they pivoted, and somewhere along the way the device became real enough that the MDR path became unavoidable. Now they need a QMS, and the common reaction is panic: "We have nothing. We have to start from zero." You do not have to start from zero. You almost certainly should not. The two years of chaos contain most of the evidence a Notified Body will want to see under the Annex IX conformity assessment route — it is just scattered, unstructured, and not yet described in the language the Regulation uses. The job of the phased approach is to convert that raw material into a real QMS without throwing the real history away. ## What survives the transition Before anything gets thrown out, be clear about what from the chaotic phase is actually useful under MDR Article 10(9). Design decisions survive. Every time the team decided to use one architecture instead of another, one component instead of another, one user interface pattern instead of another — those decisions are design inputs and design review outputs, even if nobody wrote them down as such at the time. The meeting notes, the email threads, the whiteboard photos, the Jira discussions all contain this evidence. Change history survives. Git commit history is a near-perfect change log if the commit messages are honest. Version-numbered documents in a shared drive are a primitive document control system. Pull request reviews are design reviews. Supplier correspondence survives. Emails negotiating specifications with a sensor vendor, PDFs of datasheets, quality certificates attached to purchase orders — all of this is the beginning of a supplier file. Supplier qualification is not invented at the moment the QMS goes live. It is formalised from what already happened. Risk thinking survives. Every conversation that went "what if the user does X and the device responds with Y" was informal risk analysis. Most startups have more of this than they realise, buried in Slack threads and design discussions. Complaint and incident history survives. If a beta tester reported a problem, if an early user found a bug in a hazardous context, if an internal test uncovered a near-miss — those are feedback records, and under a mature QMS they would feed the CAPA process and the PMS system. What does not survive is fiction. Anything the team wishes had happened but did not. Anything someone might want to backdate. Anything that cannot be traced to a real artefact with a real timestamp. The line between "converting real evidence into QMS records" and "fabricating records" is absolute, and the auditor will find the difference every time. ## Phase 1 — The inventory Phase 1 produces no QMS documents. It produces a map. Sit down with the founders and the first hires and list every significant artefact the company has already produced. Go through the file shares, the repositories, the issue trackers, the email archives, the chat history. For each significant artefact, record four things: what it is, when it was created, who created it, and which real activity produced it. The output is a table that might have a hundred rows for a two-year-old startup. Architecture decision notes from month three. Supplier datasheets from month five. Beta tester bug reports from month nine. Risk brainstorms from month eleven. User testing photos from month fourteen. Each row is a real piece of evidence sitting in a real location. Then, against that list, lay the core QMS process areas from MDR Article 10(9) and EN ISO 13485:2016+A11:2021: management responsibility, document and record control, design and development, purchasing and supplier control, production and service provision, CAPA, internal audit, management review, PMS linkage, risk management linkage, vigilance, PRRC. For each artefact in your list, tag which QMS process area it belongs to. Many artefacts will tag cleanly. Some will tag in two places. Some will not fit anywhere — and those are either irrelevant to the QMS (fine, leave them) or they indicate a process area where the chaotic phase produced nothing, which is a gap to close in Phase 2. Phase 1 ends when you can answer, for every Article 10(9) aspect, one of three sentences. "We already have meaningful evidence here, located in X." "We have partial evidence here, in X, and we need to add Y." "We have nothing here and we will need to start this process fresh." That map is the starting point for Phase 2. ## Phase 2 — The minimum viable QMS build Phase 2 is where the QMS actually gets written. The method is the same as [building any lean QMS for a MedTech startup](/blog/build-lean-qms-mdr-startup) — start from reality, match each applicable clause of EN ISO 13485:2016+A11:2021 to a real process, justify exclusions, write short procedures that describe what the team actually does. What changes in a transition scenario is the starting material. Because Phase 1 produced an inventory, Phase 2 does not start with blank procedures. It starts with real evidence and writes procedures that describe how that evidence was (and will continue to be) produced. A design control procedure does not describe an imaginary ideal workflow. It describes the way the team has actually been making design decisions, cleaned up and made consistent, with the specific additions the MDR requires. The discipline of Phase 2 is honest description first, improvement second. Write down what the team really does today. Then ask: what does Article 10(9) require that is missing? What does the relevant clause of EN ISO 13485:2016+A11:2021 add that your team is not doing? Close those specific gaps, not the imagined ones. For the process areas where Phase 1 found nothing — say, internal audit or management review, which startups almost always have to start fresh — run them for the first time during Phase 2 and let the first cycle be small and honest. A first internal audit that finds three real problems is more credible than a first internal audit that pretends everything is perfect. See [the minimum viable QMS post](/blog/minimum-viable-qms) for the smallest complete scope that still meets Article 10(9). One non-negotiable rule in Phase 2: every record that refers to a past event must carry its real date. If a design decision was made in month three, the record says month three. It does not get backdated to a pre-QMS date that would make the system look older. It also does not get forward-dated to the QMS start date. The honest statement is "this QMS was formally established on date X; the design history it references goes back to date Y; here is the real evidence from each period." Auditors understand that startups have a history before their QMS. They respect honest traceability. They do not respect rewritten timelines. ## Phase 3 — Audit readiness Phase 3 is the run-in period before the Notified Body walks in the door. The QMS exists, the procedures are written, the gaps are closed. What is missing is running time. A QMS is credible to an auditor when it has been running long enough to produce real records of its own operation. Design reviews that actually happened under the new procedure. CAPAs that were actually opened and closed. An internal audit that was actually performed and generated findings. A management review that actually occurred with minutes and decisions. Supplier evaluations that were actually recorded. Training sessions that were actually delivered. For Class IIa and above devices on the Annex IX route, this running-in evidence is what the Notified Body audits against. How long is long enough depends on the risk class and the specific Annex IX assessment requirements for your device, and it is the kind of question worth raising with your Notified Body contact directly. As a rule of thumb, the system should have produced at least one full cycle of each major QMS process — one internal audit cycle, one management review cycle, a representative set of CAPA records, enough supplier evaluations to show the process works — before the certification audit. During Phase 3, the team catches its own mistakes. Small non-conformities found during internal audits are opened as CAPAs, worked through, and closed with evidence. That is not failure. That is exactly what a running QMS is supposed to do, and auditors see it as a positive signal — a system that catches and corrects its own problems is a system that works. For more on the internal audit discipline during this phase, see [post 311 on internal audits under MDR](/blog/internal-audits-mdr). ## What to throw away Not everything from the chaotic phase belongs in the QMS. Some of it is noise, some of it is misleading, some of it is actively harmful if kept. Throw away outdated specifications that were never implemented. Throw away pitch deck claims that do not match the device as it is now. Throw away informal "decisions" that were made in passing and never acted on. Throw away any document that describes the device incorrectly by today's standards. Throw away anything that cannot be linked to a specific author and a specific date. Keep anything with a real timestamp, a real author, and a real connection to the device as it actually exists. The filter is not "does this look professional" — it is "is this honest evidence of something the team really did." ## Common mistakes in the transition Three patterns sink this transition more than any others. The first is throwing everything away and starting from a template. This is the Berlin template pattern applied to transitions — the founders decide the chaotic history is too messy to salvage, buy a QMS template, replace the company name, and submit it. The result is a QMS that describes a company that does not exist, with none of the real evidence the team actually accumulated. A Notified Body audit of such a system can return devastating completion percentages. See [post 276 on what a QMS actually is](/blog/what-is-quality-management-system-medical-devices) for why this fails. The second is backdating. Someone decides the QMS will "look better" if its formal effective date is earlier than it really was, or if design records are dated to match an earlier phase. This is document falsification. Notified Body auditors are trained to detect it — timestamps on files, email metadata, version history all tell the real story. Backdating turns a survivable audit into a terminal one. The third is over-scoping the catch-up. The team panics, tries to reconstruct every record a mature QMS would have, and drowns in retroactive paperwork that adds no value. The catch-up should cover what the Regulation and the standard require for the device's risk class — no more. Proportionality under Article 10(9) applies to the transition too. ## The Subtract to Ship angle The [Subtract to Ship framework applied to MDR work](/blog/subtract-to-ship-framework-mdr) says every element of a regulatory deliverable must trace to a specific obligation. In a transition, the same rule decides what from the chaotic phase is kept and what is dropped. Every artefact kept has to satisfy a clause that applies to the device. Every gap closed has to correspond to a specific requirement of MDR Article 10(9) or EN ISO 13485:2016+A11:2021. Nothing is built because "a QMS should have one." The transition is the cleanest moment to apply this discipline, because the team is already rebuilding and every decision is fresh. For the operational picture of how this scales as the team grows, see [the MedTech startup operations playbook from three to thirty](/blog/medtech-startup-operations-playbook-3-to-30). ## Reality Check — Where do you stand? 1. Do you have an honest inventory of the significant artefacts your company has produced in its pre-QMS life, with dates, authors, and locations? 2. Can you tag each of those artefacts to an Article 10(9) aspect or mark it as irrelevant to the QMS? 3. For each Article 10(9) aspect where you have nothing, have you identified what process needs to start fresh and who will run it? 4. Are any records in your draft QMS carrying dates that do not match the real timestamps of the evidence they describe? 5. Have you run each core QMS process at least once under its new procedure before your planned audit date? 6. Is there any document in your QMS that exists because a template had it, rather than because a clause or article requires it for your device? 7. If a Notified Body auditor asked you to produce the real evidence behind any QMS record from the transition period, could you walk them from the record to the original artefact in under a minute? ## Frequently Asked Questions **Can I use work done before the QMS existed as part of my design history?** Yes, if it is real and traceable. Design decisions made before the QMS was formally established are legitimate design history as long as the records carry their real dates, the authors are identifiable, and the decisions can be linked to the device as it exists now. What you cannot do is backdate the records to make the QMS itself look older. MDR Article 10(9) requires the QMS to exist and operate; it does not require the device's history to begin when the QMS does. **How long does the transition from chaos to a compliant QMS usually take?** For a small team with honest pre-QMS evidence and a clear scope, Phase 1 inventory takes one to three weeks, Phase 2 minimum viable build takes two to four months, and Phase 3 running-in before an audit typically needs several months at minimum to generate one full cycle of each core process. Timelines vary with risk class and device complexity. A Class IIa device on the Annex IX route needs longer run-in than a Class I device. **Is it acceptable to have an Annex IX audit shortly after the QMS goes live?** Acceptable is the wrong word. It is legally possible to book an audit whenever the QMS is ready, but Notified Body auditors assess whether the system is actually running. A QMS that went live last week will not have generated the records needed to demonstrate implementation. Plan the audit date backward from the date the system started running, not forward from the date you want certification. **What should I do with old templates we bought before we understood QMS?** Read them once for any useful structural ideas, then set them aside. Do not build your QMS around them. The phased approach is reality-first: your inventory and your real processes are the starting point, not a template. A template can be a cross-check at the end — "did we miss any clause this template covers?" — but never a starting scaffold. **Does the phased approach work for Class III devices?** The principle is the same but the depth is much higher. For Class III, the pre-QMS evidence has to be substantially more detailed, the Phase 2 build has to cover every process at the depth Annex IX requires for Class III, and the Phase 3 run-in is longer. Startups building Class III devices almost always need expert support during the transition because the margin for error is smaller. ## Related reading - [What Is a Quality Management System for Medical Devices?](/blog/what-is-quality-management-system-medical-devices) — the pillar post for the QMS cluster and the foundation for this transition. - [How to Build a Lean QMS for Your MedTech Startup](/blog/build-lean-qms-mdr-startup) — the seven-step method that Phase 2 is built on. - [The Minimum Viable QMS](/blog/minimum-viable-qms) — the smallest legitimate scope for an early-stage QMS under Article 10(9). - [MDR Article 10(9) and Annex IX QMS Requirements](/blog/mdr-article-10-9-annex-ix-qms-requirements) — the legal basis the transition must satisfy. - [Document Control for Early-Stage MedTech](/blog/document-control-startup) — the first procedure to get right in the transition. - [Internal Audits Under MDR](/blog/internal-audits-mdr) — the process that validates the transition during Phase 3. - [Running a QMS in a Three-Person Company](/blog/running-qms-three-person-company) — proof that a small disciplined team can pass an audit. - [MedTech Startup Operations Playbook: Three to Thirty](/blog/medtech-startup-operations-playbook-3-to-30) — how the operational picture scales after the transition. - [The Subtract to Ship Framework for MDR](/blog/subtract-to-ship-framework-mdr) — the methodology behind every decision in the phased approach. - [What Comes After Your First QMS Audit](/blog/what-comes-after-first-qms-audit) — how the system continues to mature once certification is in hand. ## 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 proportionate to risk class and type of device) and Annex IX (conformity assessment based on a quality management system and on 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. The MDR is the North Star. EN ISO 13485:2016+A11:2021 is the tool. Every phase of the transition traces back to a specific requirement of MDR Article 10(9) or the Annex IX conformity assessment route.* --- *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).*