QMS for Medical Software Startups: ISO 13485 Lean, Serving EU + US (QMSR)

Every founder building a regulated health software product eventually hits the same wall: the quality management system. You don't write it once and file it away. It's the operating system your entire regulatory file runs on, and getting its scope wrong in either direction is expensive. This guide sets out what a lean, real, dual-market QMS actually looks like for a ten-person team, and how to build one that survives contact with both a Notified Body and an FDA investigator.

In short: Since QMSR took effect on 2 February 2026, one ISO 13485-aligned quality management system serves both EU CE marking and US FDA requirements. A startup QMS needs to be lean but real: document control, design controls, risk management, supplier management, and post-market processes — sized to the team, evidenced for auditors.

On this page: Where startups overspend or underbuild · The 13485 convergence: one system, two markets · The minimum honest QMS · Design controls for agile teams · ISO 14971 as connective tissue · What eQMS tools solve — and don't · What audit day actually checks · Scaling from 5 to 50 · FAQ

Where startups overspend or underbuild the QMS

Almost every founder we talk to about quality management systems is making one of two mistakes, and the two mistakes look nothing alike from the inside.

The first is over-engineering. A team hires a quality consultant early, gets handed a 40-procedure template pack lifted from a 500-person medical device manufacturer, and tries to run all 40 procedures with three engineers and a part-time regulatory lead. Change control requires four signatures. Every code commit needs a formal design change request. The document control procedure alone runs eleven pages and requires a controlled-copy stamp workflow nobody remembers how to execute correctly. Within two quarters, engineers are quietly working around the QMS rather than through it. They push changes without updating the design history file and treat quality records as a compliance tax to pay retroactively before an audit, rather than a live record of how the product actually got built. This is the QMS nobody can actually run, and a Notified Body or FDA investigator can tell within the first hour of an audit, because the paper trail stops matching what engineers describe when asked directly what they did.

The second mistake is the mirror image: under-building. A team treats the QMS as a checkbox exercise to complete right before submission, cobbles together a document control spreadsheet and a risk register in the weeks before a Notified Body review, and discovers during that review, or worse during a post-market FDA inspection, that core processes simply don't exist in any auditable form. There's no design history file showing how requirements became a shipped feature. There's no CAPA (corrective and preventive action) process, so when a bug report comes in from the field, there's no documented trail of what was investigated, what was concluded, and what was changed. This is the QMS that fails the first real audit. The product isn't necessarily unsafe; the company simply can't produce evidence that it's systematically managing safety and performance the way the regulation requires.

Both failure modes trace back to the same root cause: nobody scoped the QMS to the actual size and actual risk profile of the team building it. ISO 13485 and QMSR do not specify a page count, a signature count, or a tool. They specify outcomes: that you can demonstrate control over design, risk, suppliers, and post-market performance. They leave the "how much process" question to the manufacturer's judgment, calibrated to the complexity of the device and the size of the organization. A ten-person team building a Class IIa clinical decision support tool needs real processes covering every clause the standard requires. (Classification itself is a separate question from QMS scope, and one under active reform: a December 2025 Commission proposal to simplify the MDR and IVDR would move much standalone software toward a Class I default — it is a proposal, not law, so treat the Class IIa example as the current Rule 11 outcome.) But the evidence burden per process, meaning how many approvers, how many templates, how many review cycles, should look nothing like what a 500-person insulin pump manufacturer runs. Pretending otherwise is where most of the wasted spend in this category originates.

The rest of this guide is built around that calibration question: what has to exist no matter what (Chapter 3), how it can exist without breaking an agile engineering culture (Chapter 4), how one system now genuinely serves both your EU and US ambitions (Chapter 2), and what changes as the team — and the audit stakes — grow (Chapter 8).

The 13485 convergence: one system, two markets (QMSR)

For years, a startup with both EU and US ambitions faced a genuinely awkward choice: build one quality system to ISO 13485 for CE marking, and a structurally different one to FDA's old Quality System Regulation (QSR, 21 CFR Part 820) for US clearance. The two standards covered similar ground — design controls, document control, corrective action, supplier management — but organized it differently enough that maintaining both in parallel meant either running two systems, or awkwardly retrofitting one standard's structure to satisfy the other's specific clause references.

That changed on 2 February 2026, when FDA's Quality Management System Regulation (QMSR) took effect, replacing the legacy QSR. The QMSR's central move is incorporating ISO 13485:2016 by reference as the base US quality system standard, with FDA-specific additions layered on top in areas where US regulatory expectations extend beyond the international standard. These include specific complaint-handling and medical device reporting provisions, US labelling requirements, and FDA's own inspection and enforcement authority, which operates independently of any ISO certification a company holds.

The practical consequence for a founder planning both markets: build one ISO 13485-aligned quality management system, and both CE marking's Notified Body review and QMSR's FDA baseline now draw on the same structural foundation. You still need to address FDA's specific additions (they don't disappear), but you are no longer maintaining two structurally distinct quality systems side by side. QMSR: What Replaced FDA's Quality System Reg covers the transition timeline, the substantive QSR-to-QMSR differences, and a worked example of what changes for a manufacturer moving off the legacy standard. If you have not yet confirmed whether your quality planning still references the old QSR by name, that page is worth reading directly, since QARA review consistently finds founders further along in this transition, on paper, than their actual documentation reflects.

Three things are worth being precise about, because "convergence" gets oversimplified in ways that create real risk if taken too literally.

First, convergence is not equivalence. An ISO 13485 certificate does not automatically satisfy the QMSR. It satisfies the substantial base the QMSR incorporates by reference, but FDA's layered additions (complaint handling specifics, medical device reporting, US-specific labelling and documentation practices) need to be specifically addressed within your ISO 13485-aligned system. Don't assume the certificate alone covers them.

Second, a compliant quality system is not a market authorization. Neither ISO 13485 certification nor QMSR compliance grants, or substitutes for, FDA clearance of your specific device, or Notified Body certification of your specific technical file. The QMS is necessary infrastructure underneath your regulatory submission, not the submission itself. A well-run QMS says nothing on its own about whether your device is safe or effective for its intended use; that's a separate, device-specific evidentiary question your technical file and clinical evaluation answer. Building an MDR Technical File and CER covers that separate, device-specific evidence layer in depth. It sits on top of, and draws heavily from, the QMS processes this guide describes, particularly design controls and risk management.

Third, the order of operations matters for teams building both markets simultaneously. If EU MDR conformity assessment is your near-term goal and US filing follows later, build to ISO 13485 as your baseline from day one. You get CE-market readiness now and QMSR-alignment essentially for free later. If US filing is first and EU is a later ambition, the same logic runs in reverse: build to ISO 13485 now rather than the old QSR structure (which, since 2 February 2026, is no longer even the operative US standard to build toward). That way you avoid the exact restructuring exercise the QMSR transition forced on companies that built QSR-first systems before the changeover.

The minimum honest QMS: what processes must exist

This is the chapter most quality-consultant sales conversations skip, because the honest answer to "what's the minimum" is less impressive-sounding than a 40-procedure binder — but it's the version that a ten-person team can actually run, and that survives an audit because it's real rather than aspirational.

ISO 13485 and QMSR both require the following process areas to exist in some auditable form, regardless of company size. What changes with size is not whether the process exists, but how much ceremony surrounds each instance of running it. The table below sets out each required process, why it's non-negotiable, and what a minimum viable version looks like for a roughly ten-person team.

Two patterns are worth naming explicitly, because both are common enough to be worth designing against from the start. The first is treating this table as a one-time build exercise: every process on this list needs to be alive, meaning it produces new records on an ongoing basis, not just a procedure document written once and left unused. An auditor who asks "show me your last three CAPAs" and finds none, or finds three that were all closed retroactively in the week before the audit, has found a real gap even if the procedure document itself reads perfectly. The second is scope creep in the wrong direction: adding elaborate sub-processes (multi-tier approval chains, separate procedures for near-identical activities) that exist to look thorough rather than because the standard or your actual risk profile requires them. Lean means matching evidence burden to actual risk and actual team size, in both directions.

Companion resource: the Lean QMS process checklist. We've built a structured checklist covering every process in the table above, mapped to the specific ISO 13485 clause and QMSR/MDR reference it satisfies, with a startup-sized minimum-viable description for each and a self-assessment column you can use before an internal audit. One example line item, so you can judge the format before requesting it: "☐ CAPA — ISO 13485 Cl. 8.5.2 (corrective action) and Cl. 8.5.3 (preventive action) / QMSR — log captures trigger, investigation, root cause, correction, and verification of effectiveness; self-assessment: do your last three closed CAPAs each have documented verification evidence, not just a status change to 'closed'?" It's available as part of our free MedTech Compass / contact flow (gated; we'll ask for a work email to send it), and it's the fastest way to sanity-check your current QMS against this table without hiring a consultant for a first pass. The scoping judgment it can't replace is covered by the expert conversation offer at the end of this guide.

How do design controls work for agile software teams?

This is the question that generates the most founder anxiety, because design controls, as written in ISO 13485 Clause 7.3 and echoed in QMSR, read like they describe a waterfall development process: define inputs, freeze a design, verify against the frozen design, validate the final output. Modern software teams — especially teams shipping AI/ML-enabled products under continuous iteration — do not work that way, and founders reasonably worry the two are incompatible.

They are not, but reconciling them requires being deliberate about a few things that agile teams don't naturally produce as a byproduct of good engineering practice alone.

Design controls do not require a waterfall process. They require traceability, at whatever cadence you actually release. The standard does not say "you must have one requirements freeze." It says you must be able to show, for whatever you ship, that a documented requirement led to a documented design output, that the output was verified against the requirement, and that the overall device was validated against user needs. An agile team that ships every two weeks can satisfy this by treating each meaningful release (not necessarily every commit) as a design control cycle: a lightweight requirements delta, the corresponding design output, verification evidence (which, for software, is often your existing automated test suite, formalized and retained rather than run-and-discarded), and periodic validation against real user needs rather than a single end-of-project validation event.

The design history file is a record, not a gate. A common and costly misconception is that design controls require a heavyweight approval gate before every code change ships. This is the over-engineering failure mode from Chapter 1 in miniature. What the standard actually requires is that you can reconstruct, after the fact, how a given feature came to be: what requirement drove it, what was verified, what was validated, and who approved the release. If your engineering team already uses structured tickets, pull requests with review, and a test suite, you likely already generate most of this evidence as a byproduct of normal agile practice. The QMS work is making sure that evidence is retained, linked, and retrievable, rather than generating it from scratch through a parallel, disconnected process.

Risk-tier your rigor. Not every change warrants the same level of design control ceremony. A cosmetic UI fix with no safety or performance implication does not need the same evidence trail as a change to a diagnostic algorithm's decision logic. IEC 62304's (IEC 62304:2006+A1:2015) software safety classification (Class A, B, or C, based on the software's potential to contribute to a hazardous situation) gives you a principled basis for this differentiation: apply full design control rigor to Class B and C changes, and a lighter-touch, still-documented process to Class A changes and pure maintenance work. This single practice — differentiated rigor by risk class rather than uniform ceremony for every change — is the highest-leverage thing an agile team can do to keep design controls honest without them becoming a development bottleneck.

AI/ML components need an explicit extension, not a separate system. If your device includes a machine learning model that gets retrained or updated post-deployment, your design control process needs to explicitly cover model versioning, retraining triggers, and performance validation against your original clinical claims as part of the same design history file — not a separate, disconnected ML-ops process that quality never sees. For teams operating under an FDA-authorized Predetermined Change Control Plan (PCCP), this connection is not optional: your PCCP commitments describe exactly what post-market model changes are pre-authorized and under what verification conditions, and your design control records need to demonstrate you actually followed that plan when a change shipped. This guidance, like standard QMS change-control practice generally, assumes a discrete, pre-specified model-update cadence — the model changes in defined, versioned steps you can bound and verify in advance. Continuously-adapting or agentic systems, where behavior shifts without a discrete release event to anchor a design control cycle to, raise open questions neither FDA's PCCP framework nor standard QMS practice has fully addressed yet — see When Medical Device AI Becomes High-Risk for what's currently known.

Validation is the piece agile teams most often shortchange. Verification (did we build the thing right) tends to map cleanly onto existing test suites. Validation (did we build the right thing for actual users in actual use conditions) is easier to skip when a team is moving fast, because it requires stepping outside the codebase and observing real or realistic use. For SaMD specifically, usability engineering evidence under IEC 62366-1:2015 is part of this validation obligation, and it needs to involve representative members of your actual intended user population, not just internal staff standing in for them. Building an MDR Technical File and CER covers this same evidence stream, Step 7 in that guide specifically, from the technical-file-assembly side. This chapter covers the process discipline that generates the evidence in the first place, upstream of the file itself.

The practical takeaway: agile development and formal design controls coexist fine at startup scale, as long as the team treats traceability as a design principle built into the workflow (linked tickets, retained test evidence, a lightweight release-level design record) rather than a parallel compliance process bolted on before submission. Teams that leave this integration until just before a Notified Body review consistently spend far more reconstructing a design history file retroactively from git history than they would have spent capturing it contemporaneously.

Why is ISO 14971 risk management the connective tissue?

If there is one process in the table in Chapter 3 that deserves to be understood as more than a line item, it's risk management under ISO 14971. This isn't a standalone deliverable that exists to satisfy one clause. It's the thread that runs through design controls, the technical file, and post-market surveillance, and a risk file that isn't actually connected to those other three areas is one of the most common, and most consequential, gaps auditors find.

Into design controls. Every design input and every verification activity should trace back to a risk the risk management file has identified. When your team makes a design decision (a threshold, a fallback behavior, a user interface choice affecting how a clinical recommendation is presented), the risk file is where the reasoning for that decision, and the evidence that the resulting risk is acceptable, should live. A design history file that doesn't reference the risk file, and a risk file that doesn't reference specific design decisions, are both incomplete on their own. Together, cross-referenced, they tell a coherent safety story an auditor can actually follow.

Into the technical file. The risk management file is one of the core evidentiary components of your MDR technical file, and the clinical evaluation report explicitly needs to address each residual risk your risk file identifies, confirming the clinical evidence supports an acceptable benefit-risk conclusion for it. Building an MDR Technical File and CER covers this connection directly in its Step 4 and Step 6. The CER cannot be written credibly in isolation from a substantially complete, genuinely lived-with risk file, and one of the most common Notified Body findings is a CER and a risk file that read as though they were produced by teams that never talked to each other.

Into post-market surveillance. Risk management does not stop at CE marking or FDA clearance. New risks surface through complaints, field performance data, and, for AI/ML-enabled devices specifically, through model drift or performance degradation observed after deployment. A properly run QMS feeds post-market data back into the risk file on a fixed cadence, and a risk file that hasn't been touched since the technical file was submitted is a visible, and common, signal to an auditor that post-market surveillance is not genuinely operating as a closed loop.

The practical habit that makes this work: treat the risk file as a living register, not a document. Every time a hazard is newly identified, through design review, verification testing, a complaint, or post-market monitoring, it gets a new or updated entry, dated, with a documented risk control measure and, critically, evidence that the control measure was verified as actually effective, not just implemented. A risk file that reads as though it was written in a single sitting at the end of development is, in our experience and consistently in Notified Body findings, one of the most recognizable red flags in the entire technical file. Reviewers who have seen hundreds of these files can tell the difference between a risk file that was lived with and one that was reconstructed for submission.

If your device incorporates AI or machine learning components, one additional discipline applies: your risk register needs a distinct lane for AI-specific risks (dataset shift, automation bias, performance degradation across subpopulations) alongside the device-level hazards ISO 14971 more traditionally captures, since these risks often surface through mechanisms like model monitoring and drift detection that a purely hardware-oriented risk process was never built to catch. This is the same overlap When Medical Device AI Becomes High-Risk describes from the AI Act's side: the same risk management discipline, extended rather than duplicated, to cover a new category of risk.

What do eQMS tools actually solve — and what do they not?

Once a founder understands the process list in Chapter 3, the natural next question is whether software can run most of it. eQMS (electronic quality management system) platforms are a mature, well-established product category, and for good reason: document control, workflow routing, training record tracking, and CAPA logging are genuinely the kind of structured, repetitive, audit-trail-heavy work that software handles better than spreadsheets and shared drives once a team crosses a certain size.

What an eQMS platform reliably solves: version control and approval workflows for controlled documents, so you're not manually tracking who approved what version when; automated routing and reminders for recurring processes like management review and internal audit, so they don't quietly slip; a searchable, timestamped audit trail across CAPAs, complaints, and training records, which is exactly the kind of retrieval an auditor's "show me" requests demand; and, for many platforms, pre-built process templates mapped to ISO 13485 clause structure, which can meaningfully shorten the initial build-out for a team starting from nothing.

What the category itself is generally clear about not solving, and this is worth taking seriously because it's the vendors' own stated positioning, not an outside critique, is the judgment layer underneath the workflow. A configurable eQMS platform structures and enforces a process. It does not decide what your risk acceptability criteria should be, does not write your clinical evaluation report's benefit-risk argument, does not determine whether your equivalence claim to a predicate device meets MDR's stricter comparability bar, and does not stand in for a qualified person's review of whether a given CAPA's root-cause analysis is actually sound rather than superficially complete. The tooling manages the container; a person with regulatory and clinical judgment still has to be responsible for what goes inside it. This is consistent with how eQMS vendors themselves typically frame their own category: as configurable workflow and document-control infrastructure that supports a quality system a manufacturer designs and owns, not as a substitute for the manufacturer's own regulatory expertise or for an auditor's independent judgment about whether the substance behind the paperwork holds up.

Two practical failure modes follow from misunderstanding this boundary. The first is treating template completion as compliance: filling in a vendor's pre-built CAPA template because the fields exist, without the underlying investigation and root-cause analysis actually being rigorous. A Notified Body or FDA reviewer reads substance, not template compliance, and a well-formatted record built on thin reasoning still generates findings. The second is under-resourcing the human review layer because the tool creates a false sense that "the system handles it." An eQMS enforces that a document went through an approval workflow; it does not enforce that the approver actually read and critically evaluated what they were approving.

The practical implication for a ten-person team: an eQMS is a genuinely good investment once your process volume outgrows what a disciplined shared drive and a couple of well-maintained logs can handle cleanly — often somewhere in the 10-25 person range for most startups, though this varies with device risk class and submission cadence. (This range, and similar team-size and timeline figures elsewhere in this guide — including the "several months" QMS build-out estimate in the FAQ and the 5/10/20/35-person scaling bands in Chapter 8 — are directional, based on patterns we've observed across early-stage MedTech teams, not a formal survey; treat them as a planning starting point, not a benchmark to cite externally.) It is infrastructure for running your QMS well, not a replacement for the regulatory and quality judgment that decides what "well" means for your specific device. Budget for both: the tool, and the person (in-house or fractional/consultant) who actually owns the judgment calls the tool can't make. Teams that buy the tool and skip the judgment are, in our experience, more likely to end up with the over-engineered-on-paper, hollow-in-practice QMS Chapter 1 describes: beautifully formatted records that don't hold up to the second or third question an auditor asks.

What do Notified Body and FDA inspections actually check?

Audit anxiety is usually worse than audit reality, but only if you know roughly what's coming. Both Notified Body assessments (for CE marking, and for ongoing surveillance audits after certification) and FDA inspections (routine QMSR surveillance inspections and, primarily for PMA devices, pre-approval inspections — a typical SaMD startup filing a 510(k) or De Novo will usually not face one) follow patterns experienced teams learn to expect, even though the specific checklist and legal authority behind each differ.

What gets requested, and in what order. Both types of auditor typically start broad and narrow in. Expect an opening request for your quality manual or top-level QMS description, your organizational chart (who owns which process), and your document control system's index — this establishes the map before the auditor starts pulling threads. From there, a Notified Body assessor typically works process by process against ISO 13485's clause structure, commonly starting with management review and internal audit records (because these two processes, if run properly, surface most of an organization's other weaknesses on their own) before moving into design controls, risk management, and CAPA. An FDA investigator, historically operating under the Quality System Inspection Technique (QSIT) framework used for QSR inspections — FDA's QMSR-era inspection approach is still being finalised, so treat the emphasis below as the historical pattern rather than a settled method — tends to focus on a smaller number of subsystems in depth (commonly CAPA, design controls, and management controls) rather than attempting comprehensive clause-by-clause coverage in a single visit.

The specific document trail an auditor pulls. A common and revealing technique, used by both types of auditor, is picking a single device change, complaint, or CAPA and tracing it end to end: the triggering event, the investigation, the root cause analysis, the corrective action taken, the verification that the action was effective, and, critically, whether the same root cause was checked against other products or processes it might also affect. This single-thread trace is where gaps in traceability become obvious fast, because it requires several different records (a complaint log entry, a CAPA record, a design change record, a verification test result) to tell one coherent, consistent story. Teams that keep these records in disconnected systems, or that write records after the fact rather than contemporaneously, are the ones who struggle most under this kind of trace.

Common gaps found, across both types of audit. CAPAs closed without documented evidence that the corrective action was actually verified as effective — a status change to "closed" is not evidence. Risk files that identify a hazard and a control measure but never document that the control measure was tested or otherwise verified. Design history records that exist for major releases but have visible gaps for smaller, still-safety-relevant changes. Training records that are generic ("completed onboarding") rather than tied to the specific competence a specific role requires. Supplier qualification files that list approved suppliers without a documented rationale for why they were qualified, or evidence of periodic re-evaluation. And, especially relevant to this audience, post-market surveillance data (support tickets, field performance monitoring, complaint trends) that is collected but never demonstrably fed back into the risk file or CAPA process — a closed loop that isn't actually closed.

Interview technique matters as much as document review. Both Notified Body assessors and FDA investigators routinely interview staff directly, and a common purpose is checking whether what an engineer or quality team member describes in conversation matches what the records say happened. This is exactly why the over-engineered QMS from Chapter 1 fails audits: if the documented procedure requires a workflow the team doesn't actually follow day to day, the mismatch surfaces the moment someone is asked to walk through how a recent change actually happened, independent of what any document claims.

What "audit-ready" actually means for a lean team. It does not mean anticipating every possible question. It means every process in the Chapter 3 table is genuinely alive, producing real, dated, connected records as a byproduct of how the team actually works, so that when an auditor pulls any single thread, it leads somewhere coherent rather than to a gap papered over the week before the visit. Teams that treat quality records as a live operating history, generated as work happens, consistently have shorter, less contentious audits than teams that treat the QMS as a retrospective reconstruction exercise performed under audit-preparation pressure.

How does the QMS scale from 5 to 50 people?

A QMS that's right-sized at five people will not still be right-sized at fifty, and trying to freeze it in its early form as the company grows is its own failure mode, distinct from but related to the two described in Chapter 1. Here is a practical roadmap for what typically needs to change at each stage.

5-10 people: founding QMS. At this stage, the QMS is usually owned part-time by a founder or a fractional/consultant quality lead, layered directly onto the engineering team's existing workflow rather than run as a separate function. The full Chapter 3 process list needs to exist, but ownership is concentrated in one or two people, and most processes run on the disciplined-shared-drive-and-log tooling described in Chapter 6 rather than a dedicated eQMS. The main risk at this stage is under-building — skipping processes that don't feel urgent yet (supplier management, formal internal audit) because there's no immediate pressure to run them, and then discovering the gap during first Notified Body or FDA contact.

10-20 people: first dedicated quality hire. This is typically the point where a company brings on its first full-time quality or regulatory hire, rather than running the QMS through a founder's part-time attention or an external consultant alone. Process ownership starts distributing: engineering owns design control execution with quality oversight, rather than quality owning everything directly. This is usually also the point where an eQMS platform starts paying for itself, because document and record volume has outgrown what a shared drive handles cleanly. Internal audit needs to become a genuinely scheduled, resourced activity rather than an ad hoc exercise squeezed in before a known external audit.

20-35 people: multi-function quality organization. By this stage, most companies need more than one dedicated quality/regulatory person, and process ownership needs clearer separation of duties — the person executing a process and the person auditing it should not be the same individual, which becomes harder to guarantee informally as headcount grows past what a founder can personally track. This is also typically when companies with multi-market ambitions (EU and US simultaneously, per Chapter 2, or additional markets like Saudi Arabia under SFDA's MDMA (Medical Device Marketing Authorization) framework) need to formalize how market-specific additions layer onto the shared ISO 13485 base, rather than relying on one person's institutional knowledge of what's different where. CAPA volume and complaint volume both typically increase materially once a product has meaningful market presence, which stress-tests whether the CAPA process actually scales or was only ever sized for occasional use.

35-50+ people: mature, auditable-at-scale QMS. At this stage, the QMS typically needs a genuinely dedicated quality function with clear leadership (a VP Quality or Head of Regulatory Affairs, not a fractional role), a formal internal audit program covering the full process set on a defined schedule rather than opportunistic coverage, and quality metrics that management review actually uses to drive decisions — CAPA aging, complaint trends, audit finding closure rates — rather than metrics tracked for their own sake. Supplier management usually needs to formalize further as the supplier base grows past what informal relationship management can track. This is also commonly the stage at which companies previously running on the lean shared-tooling approach from Chapter 6 either upgrade to a more capable eQMS tier or add dedicated headcount specifically to manage the eQMS configuration itself, because the tooling question and the staffing question become genuinely intertwined at this scale.

The throughline across every stage: the processes required by ISO 13485 and QMSR do not change with headcount — document control, design controls, risk management, CAPA, and the rest are required from day one. What changes is who owns each process, how much tooling supports it, and how much separation of duties and formal scheduling surrounds it. A company that tries to keep running its 8-person QMS unchanged at 40 people will find that informal ownership and ad hoc scheduling — tolerable gaps at small scale — become exactly the kind of finding a mature-stage audit is designed to catch.

Frequently Asked Questions

Do we need ISO 13485 certification, or just a quality system built to the standard? For CE marking, a Notified Body's conformity assessment for Class IIa and above effectively requires you to demonstrate an ISO 13485-aligned quality system as part of that assessment. Many teams pursue formal third-party ISO 13485 certification as part of or alongside this process, though the certificate itself and MDR conformity assessment are related but formally separate. For QMSR, formal ISO 13485 certification is not itself mandated (the QMSR incorporates the standard's substance by reference into FDA's regulation), but building to the standard, certified or not, is the practical baseline either way. Most dual-market teams find pursuing formal certification worthwhile because it provides independent verification and is often expected or requested by investors, partners, and some customers, even where not strictly mandatory.

Can a fractional or consultant quality lead run our QMS instead of a full-time hire? Yes, and it's a common and reasonable approach at the 5-10 person stage described in Chapter 8, provided the arrangement is genuinely "at disposal" in practice: actively involved in ongoing process ownership, not brought in only before audits. The same logic applies here as with the PRRC role under MDR Article 15, which has an explicit micro/small enterprise carve-out for exactly this kind of external, part-time arrangement; PRRC Under MDR Article 15: What to Know covers that specific role in depth. Note that this is an EU MDR-specific concept — QMSR and FDA practice have no directly equivalent named micro/small-enterprise carve-out, so if you're building US-first, don't assume the same formal flexibility applies on the FDA side; the fractional-arrangement logic above still holds as practical guidance, it just isn't backed by an explicit regulatory carve-out the way PRRC is. The key risk to manage is continuity: a fractional arrangement that leaves gaps in institutional knowledge between engagements is a real audit vulnerability, so clear documentation and handoff practices matter more, not less, than in a full-time setup.

How long does it take to build a QMS from nothing? This varies with device risk class and how much of the Chapter 3 process list already exists informally, but most teams building a genuinely audit-ready QMS from a standing start should expect several months of concentrated work, not weeks. Document control and risk management processes can be stood up relatively quickly, while a credible design history file and a CAPA process with real closed examples take longer because they need to accumulate genuine records, not just procedure documents. Starting early and building processes contemporaneously with development, rather than retrofitting them before a submission, is consistently faster in total than the alternative.

What's the single most common QMS mistake you see in first-time Notified Body or FDA contact? A QMS that looks complete on paper but isn't genuinely lived with: procedures that exist as documents but don't match what the team actually does day to day, discovered the moment an auditor interviews an engineer directly or traces a single change end to end through the record trail, as Chapter 7 describes. The fix isn't more documentation; it's tighter integration between the QMS and the team's actual workflow, so the records are a byproduct of real work rather than a parallel compliance exercise performed retroactively.

Does an AI/ML component in our device change what our QMS needs to cover? Yes, in two specific places rather than across the whole system. Your design control process needs to explicitly extend to model versioning, retraining, and performance validation (Chapter 4), and your risk management file needs a distinct lane for AI-specific risks like dataset shift and performance degradation across subpopulations (Chapter 5), alongside the device-level hazards ISO 14971 more traditionally captures. If you're also navigating EU AI Act obligations, When Medical Device AI Becomes High-Risk covers how that framework's technical documentation and risk management requirements extend, rather than duplicate, the same underlying QMS processes described in this guide.

Should we buy an eQMS platform before we have any processes running, or build processes first? Build the processes first, even in a lightweight form, and bring in tooling once you understand what you're actually trying to run at scale. Buying a platform before you've established what your document control, CAPA, and risk management processes actually need to capture often results in a team configuring a powerful tool around a process that was never properly scoped, which is a more expensive way to arrive at the same over-engineering problem Chapter 1 describes. Chapter 6 covers what an eQMS reliably solves once you're ready for it, and what it was never designed to solve regardless of timing.

---

If you're not sure whether your current quality system would hold up against the process table in Chapter 3, or you're building from a standing start and want the sequencing right the first time rather than reconstructed under audit pressure later, book an expert conversation with our regulatory and quality team. That's the single best next step if you want a specific answer for your device. Prefer to self-serve first? The same free MedTech Compass / contact flow also gets you the Lean QMS process checklist from Chapter 3 and the free MedTech Compass of where your quality system likely stands relative to the QMSR and ISO 13485 baseline. Either is a reasonable starting point before that conversation, not a replacement for it.

Where next: Building an MDR Technical File and CER · QMSR: What Replaced FDA's Quality System Reg · PRRC Under MDR Article 15: What to Know · Reuse Your CE Technical File for FDA and SFDA

Last reviewed 2 July 2026. The QMSR effective-date material in Chapter 2 reflects the confirmed 2 February 2026 effective date; this page will be updated if FDA issues further QMSR implementation guidance materially affecting the substance above.