A multi-site MedTech startup still runs one QMS, not several. Clause 4.1 of EN ISO 13485:2016+A11:2021 requires the organisation to define the scope of its QMS and control the processes needed for it regardless of where the people sit. The work is to pick one document system, one change control, one training record set, and one internal audit programme, then make every site and every remote contributor operate against that single spine. The hard part is not the tooling. The hard part is discipline: one process, executed the same way whether the person runs it from Graz, Tallinn, or a kitchen table in Lisbon.

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

TL;DR

  • MDR Article 10 places the QMS obligation on the manufacturer as a legal entity, not on a specific office. Wherever the work happens, the manufacturer owns it.
  • EN ISO 13485:2016+A11:2021 Clause 4.1 requires one defined QMS scope with documented processes. Multi-site and remote do not create an exemption — they create a design problem the QMS has to solve.
  • One QMS for the whole company beats federated site-level QMS attempts every time. Federated systems drift, diverge, and break at the first notified body audit.
  • Document control under Clause 4.2.4, training records under Clause 6.2, and internal audits under Clause 8.2.4 are the three places where multi-site startups typically fail first.
  • A cloud-native QMS tool is usually the right answer for distributed teams, but the tool does not replace the procedural discipline — it only makes the discipline executable.

Why the multi-site question is now a startup question

Ten years ago, multi-site MedTech was a big-company problem. One manufacturing plant in Ireland, one design centre in Germany, one servicing hub in Singapore. Notified bodies knew the pattern and audited each site on a rotation. Startups rarely had to think about it.

That has changed. The modern MedTech startup is distributed by default. The founding CTO is in Graz. The first two software engineers are in Tallinn and Porto. The regulatory lead is fractional and works from Vienna. The clinical advisor is in Zurich. The first clinical site is in Berlin. There may not be a "headquarters" in any real sense — there is a registered legal entity, a couple of laptops, and a shared cloud drive.

That setup is a multi-site QMS from the moment the company incorporates, even if nobody uses the phrase. The QMS has to work across time zones, across jurisdictions, across personal broadband connections, and across people who have never been in the same room. None of that changes the legal obligation under MDR Article 10. It only changes the way the obligation has to be built.

The question is not whether a distributed startup can run a compliant QMS. They can, and several do. The question is how to build a QMS that is genuinely one system, not a polite fiction over the top of three or four uncoordinated ones.

The multi-site challenge — one QMS, many desks

Under EN ISO 13485:2016+A11:2021 Clause 4.1, the organisation has to establish, document, implement, and maintain a QMS and maintain its effectiveness. The clause speaks about "the organisation" as a single actor with a defined scope. It does not permit two parallel QMS for the same manufacturer. MDR Article 10 reinforces this at the legal level: the manufacturer is responsible for compliance, and the manufacturer is one legal person.

The common failure mode in distributed startups is the accidental federation. Each site builds its own folder structure. Each site develops its own change-request habit. Each site trains its own people in its own way. At first it looks pragmatic — each team moves fast in its own context. Six months later there are three document versions of the same procedure, two incompatible CAPA trackers, and a management review that has no idea what the smaller site has been doing.

The fix is not to centralise every decision. The fix is to define one spine — document control, training records, CAPA, change control, internal audit, management review — and run every site and every remote contributor against that single spine. Local practice can exist for things the spine explicitly delegates. Everything else has to converge.

For the notified body, the test is simple. When the auditor opens the document system from anywhere in the world, do they see the same controlled documents, the same records, the same evidence trail? If yes, the QMS is one QMS. If no, it is not, no matter what the quality manual claims.

Document control across sites

Clause 4.2.4 of EN ISO 13485:2016+A11:2021 is the single most important multi-site clause. It requires that documents are controlled — approved before issue, reviewed and re-approved when updated, current versions available at points of use, obsolete versions removed from use, and changes identifiable.

In a distributed team, every one of those requirements has a failure mode.

"Approved before issue" fails when engineers edit a procedure in their local copy and never push it through the formal review. "Current versions available at points of use" fails when the remote clinical advisor is still working from last quarter's template because nobody told her it had changed. "Obsolete versions removed from use" fails when an old PDF lives on a personal laptop long after the revision. "Changes identifiable" fails when the change log is maintained by the site that happens to remember, not by the system.

The only control that actually works in a distributed team is a single source of truth for controlled documents, with enforced check-out and versioning, that everyone accesses through the same front door. No local mirrors. No "working copies" on personal drives that later become the reference. No email attachments of procedures.

The practical rule is strict: if a document is not in the controlled system, it does not exist for QMS purposes. A procedure saved on a contributor's laptop and nowhere else has no status. A template shared over chat is a conversation, not a document. The controlled system is the only surface that the QMS recognises.

This is a cultural change more than a tooling change. Distributed teams build habits around quick sharing. The quality system needs those quick shares to route through the controlled repository, not around it.

Training records for distributed contributors

Clause 6.2 of EN ISO 13485:2016+A11:2021 requires the organisation to determine the necessary competence for personnel performing work affecting product quality, provide training or take other actions to achieve the necessary competence, and maintain appropriate records of education, training, skills, and experience.

In a single-office startup this is a filing-cabinet problem. In a distributed startup it is a logistics problem. The regulatory lead in Vienna has to confirm that the software engineer in Tallinn has read and understood the latest revision of the software lifecycle procedure. The engineer has to acknowledge it. The acknowledgement has to become a record. The record has to be retrievable by the auditor.

Four rules make this work across remote teams.

First, every new revision of a procedure triggers a named read-and-acknowledge requirement for every person in scope. No revision is closed until every required acknowledgement is on record.

Second, acknowledgements are captured inside the QMS tool, not by email. Email receipts are not controlled records. A checkbox inside the document management system with a timestamp and a user identity is.

Third, competence is assessed, not just claimed. Reading a procedure is not the same as being competent in it. For critical activities — software release, design review, risk analysis — the competence record has to show that the person has either demonstrated the activity under supervision or passed an internal assessment.

Fourth, when contractors or fractional staff perform work affecting product quality, they are in scope for Clause 6.2. Their training records sit in the same system as the employees'. "They are external" is not a reason to leave them out of the training matrix. The manufacturer owns the quality of the work regardless of who holds the contract.

Internal audits across sites

Clause 8.2.4 of EN ISO 13485:2016+A11:2021 requires internal audits at planned intervals to determine whether the QMS conforms to planned arrangements and the requirements of the standard, and whether it is effectively implemented and maintained. In a multi-site context this has a specific consequence: the internal audit programme has to cover every site and every location where QMS-relevant work happens, on a schedule that the organisation can justify.

The temptation in a distributed startup is to audit only the main office because that is where the documents live. That is not enough. If the software team sits in Tallinn, the internal audit has to sample the Tallinn work — a video call with screen shares is acceptable, but the sample has to be real. If a remote contractor handles complaint intake, their process has to be audited as it actually runs, not as an idealised central version.

A working pattern for a small distributed startup is one annual internal audit that explicitly includes every location and every remote contributor, plus a smaller mid-year thematic audit focused on a specific process (for example, design change control or supplier evaluation). The full-system audit confirms the spine is intact. The thematic audit catches the drift that always builds up between full audits.

Internal audit findings are then tracked in the same CAPA system the rest of the company uses. There is no "Tallinn CAPA log" or "clinical site CAPA log." There is the CAPA log.

The cloud QMS option

The honest answer for most distributed MedTech startups is that a cloud-native QMS tool is the right choice. The alternatives — shared drives with naming conventions, local file servers with VPN access, printed binders in one office — all degrade under remote pressure. A purpose-built cloud QMS enforces document control, training records, change control, and CAPA in ways that scale with distance.

This is not a vendor endorsement. Several tools are credible. The selection criteria are what matter.

A credible cloud QMS for a distributed startup must provide controlled document versioning with enforced review and approval workflows, a training matrix with per-user acknowledgement records, a CAPA and change-control module with full audit trail, role-based access control mapped to the QMS roles defined in the quality manual, export of every record as an auditable artefact, and data hosting that is compatible with the manufacturer's privacy and data-protection obligations.

Two warnings, though. First, the tool does not replace the QMS. It only executes it. A bad QMS inside a good tool is still a bad QMS — worse, because the tool hides the problem behind a polished interface. Build the QMS on paper first, then configure the tool to run it, not the other way around.

Second, tool lock-in is a real cost. A startup that picks a niche QMS tool and later discovers it cannot export its document history faces a painful migration. During selection, test the export. Pull a record out in a format that a notified body can read. If that is not possible, pick a different tool.

The management review pattern

Clause 5.6 of EN ISO 13485:2016+A11:2021 requires top management to review the QMS at planned intervals to ensure its continuing suitability, adequacy, and effectiveness. For a single-site team this is an in-person meeting. For a distributed startup it is a structured video call with a defined input pack and a formal output record.

The inputs to a distributed management review are the same as for any other: audit results, feedback from customers, complaint trends, process and product conformity data, CAPA status, follow-up from previous reviews, changes that could affect the QMS, recommendations for improvement, and the status of regulatory and standards updates. What changes is how the inputs are gathered. A distributed team needs a pre-read circulated at least a week before the meeting, with each QMS process owner — wherever they sit — contributing their section.

The output record must be a minuted decision document that names attendees, records decisions, assigns actions with owners and due dates, and is signed off by top management. A video recording is not a record under Clause 5.6. The minute is.

One cadence that works for small distributed teams: an annual full management review that covers every required input, a quarterly lightweight review focused on KPIs and CAPA status, and an on-demand review triggered by significant events (a serious incident, a failed audit, a major design change, a new regulation). All three feed into the same record stream.

Common mistakes

  • Running parallel QMS instances per site and calling the result "one system." The notified body will see it in ten minutes.
  • Letting contractors and fractional staff operate outside the training matrix. If they touch quality-relevant work, they are inside Clause 6.2 whether their contract is permanent or not.
  • Allowing uncontrolled working copies of procedures to live on personal laptops. The first audit surfaces them.
  • Treating video calls as records. They are not. Only the minutes and action logs are.
  • Picking a cloud QMS tool that cannot export records cleanly. The lock-in becomes a regulatory risk.
  • Auditing only the main office because it is easier. The remote sites are where drift accumulates.

The Subtract to Ship angle

The Subtract to Ship rule for multi-site QMS is the same rule as for every other QMS decision in the Subtract to Ship framework for MDR: every process, document, and control has to trace back to a specific clause of EN ISO 13485:2016+A11:2021 or a specific article of MDR. If it cannot, it comes out.

Applied to multi-site specifically, the subtraction is against federation. Every "site-local" document, every "site-local" training record, every "site-local" CAPA tracker is a candidate for subtraction. The remaining system is one spine that every site executes identically. The simplification is the compliance move.

The mistake distributed founders make is adding more process to compensate for distance — more coordination meetings, more status documents, more parallel trackers. The correct move is the opposite: fewer systems, each one used by everyone, with no exceptions. Less surface area, less drift, less to audit, fewer findings.

Reality Check — Where do you stand?

  1. If your notified body auditor opened your document management system today from the Tallinn laptop, would they see the same controlled documents as from the Vienna laptop?
  2. Can you produce a training record, in under two minutes, showing that every current team member has acknowledged the latest revision of your software lifecycle procedure?
  3. Does your last internal audit explicitly cover every remote site and every fractional contributor, or did it only sample the main office?
  4. Is every CAPA, from every site, in a single tracker — or do you have parallel logs that need reconciliation?
  5. Was your most recent management review a recorded meeting or a minuted decision record with assigned actions?
  6. Are any of your controlled procedures currently living on a personal device as an editable working copy?
  7. If you had to switch QMS tools next quarter, could you export your full record history in a format a notified body could read?

Frequently Asked Questions

Does MDR require a separate QMS for each site of a multi-site manufacturer? No. MDR Article 10 places the QMS obligation on the manufacturer as a legal entity. EN ISO 13485:2016+A11:2021 Clause 4.1 requires one defined QMS scope. The manufacturer runs one QMS; multiple sites operate within that single system.

How does a fully remote startup without a physical office prove site control to a notified body? The notified body audits the QMS, not the real estate. A remote-first startup passes audit by showing a single controlled document system, a training matrix covering every contributor, internal audit evidence that sampled the actual distributed work, and management review records. The auditor interviews remote staff over video during the audit.

Do contractors and fractional staff need to be in the training matrix? Yes, if they perform work that affects product quality or quality system processes. Clause 6.2 of EN ISO 13485:2016+A11:2021 applies to "personnel performing work affecting product quality" regardless of employment status. A fractional regulatory lead, a contract software engineer, and an external clinical advisor all sit inside the training matrix.

Is a cloud QMS tool mandatory for distributed teams? Not mandatory, but practically necessary. A distributed team using shared drives and naming conventions will fail one of the document control requirements under Clause 4.2.4 within the first year. A purpose-built cloud QMS is the most reliable way to meet the requirement at distance.

Can internal audits be done entirely over video calls? Yes, and for distributed teams they often must be. The requirement under Clause 8.2.4 is that the audit is effective, not that the auditor is physically present. Video audits work if the samples are real, the evidence is reviewed live, and the findings are documented in the same way as an on-site audit.

How do you handle time zones for management review meetings? The meeting time is a logistics problem; the QMS requirement is the structured input pack, the attendee record, and the minuted decisions. For teams spread across more than four time zones, asynchronous review cycles work — pre-read circulated, individual written contributions collected, decision meeting held with as many attendees as possible, absent members sign off on the minutes after the fact.

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). Official Journal L 117, 5.5.2017.
  2. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Clauses 4.1 (general QMS requirements), 4.2.4 (control of documents), 5.6 (management review), 6.1 (provision of resources), 6.2 (human resources), and 8.2.4 (internal audit).

This post is part of the Quality Management Under MDR series in the Subtract to Ship: MDR blog. Authored by Tibor Zechmeister and Felix Lenhard. If your distributed team is trying to stitch one coherent QMS across multiple sites and fractional contributors and the seams are starting to show, Zechmeister Strategic Solutions has walked teams through this exact problem.