Managing the MDR technical file with a three-person team is not only possible, it is frequently cleaner than the equivalent job at a thirty-person company. The requirements are the same — Regulation (EU) 2017/745 Article 10(4) obliges the manufacturer to draw up and keep up to date technical documentation in accordance with Annex II, regardless of team size — but the method is different. A small team wins by picking one structure (Annex II, directly), one document control system that matches EN ISO 13485:2016+A11:2021 clause 4.2.4, and a weekly cadence that nobody is allowed to skip. Ownership must be named on every section. Discipline must survive the week someone is in a hurry. Tools help, but discipline is the load-bearing element.

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

TL;DR

  • A three-person MedTech team can manage the full Annex II technical file if the structure mirrors Annex II from day one and every section has a named owner.
  • MDR Article 10(4) of Regulation (EU) 2017/745 applies identically to a three-person company and a three-hundred-person company. The volume of work scales with the device, not with the team.
  • Document control under EN ISO 13485:2016+A11:2021 clause 4.2.4 is non-negotiable: approved before issue, current revision identified, available at points of use, obsolete versions prevented from unintended use.
  • Weekly cadence beats ad-hoc heroics. A 45-minute weekly review of the file catches drift before it becomes a finding.
  • A Lower Austria three-person company we worked with passed its first Notified Body audit with zero nonconformities. Structure, ownership, and discipline were the reasons — not headcount.

The three-person reality

A Lower Austria company we worked closely with had exactly three people. One founder-engineer who owned the device. One part-time clinician who owned the intended purpose and the clinical evaluation. One operations lead who owned the QMS and the document control system. That was the whole company. Their first Notified Body audit produced zero nonconformities on technical documentation. Three people. One product. A clean certificate.

The regulation did not bend for them. Article 10(4) still applied. Annex II still demanded every section. Annex I still required every applicable general safety and performance requirement to be addressed. Their advantage was not scope relief. It was that each of the three people knew exactly which sections of the file were theirs, and the file itself was built to the Annex II structure from the first week of the project so nothing had to be reorganised later.

Against that pattern, we have seen thirty-person companies arrive at the same audit with a treasure hunt of a file — sections scattered across shared drives, cross-references pointing to renamed documents, nobody quite sure which version of which procedure was current. The extra twenty-seven people did not help. In several cases they made it worse, because more authors meant more drift and more places for the file to contradict itself.

Team size is not the limiting factor. Structure and ownership are.

Structure first, always

The single highest-leverage decision a small team makes on the technical file is to adopt Annex II of Regulation (EU) 2017/745 as the table of contents from day one. Not a custom structure. Not a "we will reorganise later" shared drive. The Annex II outline, section by section, as the skeleton under which every document lives.

Annex II defines the order: device description and specification, information to be supplied by the manufacturer, design and manufacturing information, general safety and performance requirements checklist, benefit-risk analysis and risk management, product verification and validation, and (where applicable) additional information for specific device groups. The pillar post on technical documentation under MDR walks through each section in detail. For small-team management, the point is that you never invent your own structure. You inherit the Annex II one.

The reason structure-first matters more for a small team than for a large one is that a small team cannot absorb reorganisation work later. A thirty-person company can assign two people to spend a month restructuring a messy file. A three-person company cannot — every hour spent on reorganisation is an hour not spent on the device itself. Getting the structure right once, at the start, is the only affordable option.

The Lower Austria team did this literally. They printed the Annex II table of contents and pinned it to the wall on week one. Every document produced thereafter had a pre-assigned home. When the first Notified Body audit came, the auditor opened the file, recognised the structure immediately, and started sampling. No friction. The build-from-day-one discipline is exactly this move.

Tools versus discipline

Small teams obsess about tools. Which eQMS should we buy? Is Google Drive enough? Can we run this on Notion? The tool question matters, but it is a second-order question. The first-order question is whether the team has the discipline to run whatever tool they pick.

A tool enforces the mechanical parts of document control that clause 4.2.4 of EN ISO 13485:2016+A11:2021 demands: approved before issue, changes identified, current revision status visible, obsolete versions prevented from unintended use. A good eQMS automates most of this. A disciplined shared-drive setup can satisfy it manually. An undisciplined eQMS satisfies none of it, because the team clicks through approvals without reading.

For a three-person team, the practical options are the ones covered in the document control for startups post: a lightweight eQMS, a Git-based workflow if the team is fully technical, or a structured shared drive with a controlled document list. All three can work. None of them work on their own. The team has to actually run the approval workflow, actually remove obsolete versions, actually keep the controlled document list current.

The split that works: pick the simplest tool that enforces the clause 4.2.4 mechanics, and put the team's discipline into the parts the tool cannot enforce — writing procedures that match real work, reading before approving, updating when the process changes. A small team that picks an elaborate tool and skips the discipline produces a beautiful audit trail for a QMS nobody follows. A small team that picks a simple tool and runs it with discipline passes audit.

Ownership assignment: every section has a name

On a three-person team, every Annex II section and every Annex III component has exactly one named owner. Not "the team." Not "whoever has time." One name, written down, visible to everyone.

A typical ownership map for a three-person MedTech startup looks something like this. The founder-engineer owns the device description, design and manufacturing information, the GSPR checklist (Annex II section 4), the verification and validation evidence, and the risk management file. The clinical lead (even if part-time) owns the intended purpose, the labels and instructions for use, the clinical evaluation, and the benefit-risk analysis. The operations lead owns the QMS itself, the document control system, the training records, and the Annex III post-market surveillance documentation. Every section has exactly one of these three names next to it.

Why single ownership matters: clause 4.2.4 requires that documents are approved before issue and that changes are identified. On a small team, the approval workflow only works if somebody is clearly accountable for each document. If two people share ownership, both assume the other will handle it, and nothing gets approved. If nobody owns it, it drifts out of date and becomes an audit finding.

Single ownership does not mean a single author. Documents are frequently drafted by one person, reviewed by another, and approved by a third — that is exactly the three-role workflow clause 4.2.4 implies. What single ownership means is that one named person is accountable for the document being current, correct, and findable. When the auditor asks "who owns the risk management file?" there is one name in the answer.

Update cadence: weekly, non-negotiable

The failure mode we see most often on small teams is not that documents are never updated. It is that they are updated in bursts — heroic weekends before a deadline — with months of drift in between. Bursty updates produce files that are out of date on the day of the audit because the last burst was three months ago and the device has moved on.

The fix is a fixed weekly cadence. Forty-five minutes, same day, same time, every week. The whole team reviews the controlled document list, walks through the sections that changed that week, flags anything that needs an update, and either updates it on the spot or assigns it with a deadline.

Weekly is the right interval for small teams because monthly is too slow — a month of drift on a fast-moving startup is enough for three major design changes to go unrecorded — and daily is too heavy for work that mostly consists of small touches. The weekly meeting creates a forcing function for keeping the file in sync with reality. It also creates a forcing function for the three owners to stay aware of each other's sections, which is how the cross-references between sections stay intact.

The weekly review is not a replacement for the formal approval workflow required by clause 4.2.4. It is the trigger that tells the team when a formal update is needed. The actual approval happens through the documented procedure, with author, reviewer, and approver roles, and with the signatures recorded.

Review discipline: the three-role rule at two-person scale

Clause 4.2.4 expects documents to be approved before issue. The practical implementation is three roles: author, reviewer, approver. On a three-person team, these three roles are often played by the same three people — but the three acts must remain distinct. One person drafts. A different person reads and challenges. A different person signs off after the challenges are addressed.

What small teams are tempted to do, and should not, is collapse the roles when they are in a hurry. "I wrote it, you approve it, we will skip the review." That collapse is the single most reliable way to produce document-control findings. The auditor asks the approver what changed in the last revision, the approver does not know, and the finding writes itself.

For the very smallest teams — sole founders with one external partner — the reviewer role can be played by an external regulatory sparring partner rather than a second internal engineer. This is legitimate under the standard as long as the reviewer is competent and the review is genuine. It is one of the places where the DIY versus consultant question has a clean answer: the external reviewer does not replace internal ownership, but they can provide the second pair of eyes that clause 4.2.4 needs.

The three-role discipline also protects small teams against blind spots. A founder who wrote the device description sees the device they meant to build. A reviewer who was not at the whiteboard last week sees the device the document actually describes. The gap between the two is where most findings live.

What falls through the cracks on small teams

Even disciplined small teams have predictable weak spots. The pattern is consistent enough to list.

Cross-references between sections. The GSPR checklist in Annex II section 4 points to evidence in section 6. When evidence is updated, the checklist's reference is easy to forget. On a small team with one person holding both ends of the reference, the fix is mechanical — update the reference as part of the weekly cadence — but it requires naming the task explicitly.

The intended purpose on the website. Marketing claims on a public website are part of the intended purpose and therefore part of the technical file. Small teams update the website in the course of normal business and forget that the change propagates into regulatory scope. The post on marketing claims and intended purpose covers the pattern. On a small team, the operations lead should own a weekly check that the website has not drifted away from the file.

Annex III post-market surveillance documentation. Small teams that focus on getting to Annex II often treat Annex III as a later problem. It is not a later problem — Article 83 applies to every class, including Class I, and MDCG 2025-10 describes what proportionate PMS looks like. The fix is to start the Annex III documentation at the same time as the Annex II structure, not after.

Training records under clause 6.2. When a procedure is updated, the people affected must be trained on the new version. Small teams often do the training informally ("we talked about it at the standup") and forget to record it. No record means no training from the auditor's perspective. Every procedure update triggers a training record.

Obsolete versions on personal laptops. Clause 4.2.4 requires that obsolete documents be prevented from unintended use. On small teams where everyone works from their own laptop, old versions linger. A simple weekly habit of deleting superseded PDFs from personal devices solves it.

Common mistakes small teams make

  • Postponing the file until the last six months. The file is built from day one or it is never built cleanly. The phase-one discipline is the prerequisite.
  • Buying an eQMS before understanding what they need. Small teams frequently buy a tool before they have a document control procedure, then bend the procedure to fit the tool. The procedure should come first; the tool should then enforce it.
  • Collapsing author, reviewer, and approver into one person "to move faster." The speed is illusory — the findings at audit cost ten times more than the time saved.
  • Treating the weekly cadence as optional. The week it becomes optional is the week drift begins. Put it on the calendar and protect it the way you protect a customer meeting.
  • Assuming the external consultant will hold the file together. The manufacturer holds the file per Article 10(4). A consultant can help; the accountability does not transfer.

The Subtract to Ship approach

The Subtract to Ship framework for MDR applied to small-team documentation management produces a short list of what stays and a long list of what goes. What stays: the Annex II structure, the three named owners, the weekly cadence, the three-role approval workflow, and every document that traces to a specific Annex II section or Annex I GSPR. What goes: every template section that does not apply to the device, every review layer that duplicates another, every appendix that nobody reads, every meeting that does not produce a decision.

A three-person team cannot afford bloat. Subtract to Ship gives them permission to cut it, grounded in the specific MDR articles and annexes that the remaining work traces to. The result is a file that is leaner than the average, more findable than the average, and — as the Lower Austria three-person outcome shows — frequently cleaner at audit than files five times its size.

Reality Check — Where do you stand?

  1. Does the top-level structure of your current technical file match Annex II exactly, or did your team invent a different structure?
  2. Can you name, for every Annex II section and every Annex III component, exactly one person on your team who owns it?
  3. Do you have a fixed weekly review cadence on the calendar, and has it actually run every week for the last eight weeks?
  4. When was the last time a document in your file was approved without being read by the approver? How would you know if it happened?
  5. Are the cross-references between your GSPR checklist and your evidence sections resolvable today, to current versions of real documents?
  6. Does the intended purpose on your website match the intended purpose in your device description section? When did you last check?
  7. If someone left the team tomorrow, could the remaining people find and update every document that person owned?
  8. Is your document control procedure itself under document control, per clause 4.2.4 of EN ISO 13485:2016+A11:2021?

Frequently Asked Questions

Can a three-person team really manage the full MDR technical file? Yes. We have seen it first-hand — a Lower Austria three-person company passed its first Notified Body audit with zero nonconformities on technical documentation. The requirements of Article 10(4) of Regulation (EU) 2017/745 and Annex II apply identically regardless of team size. What makes it possible is structure (Annex II from day one), ownership (every section has one named owner), and cadence (a non-negotiable weekly review). Headcount is not the limiting factor.

Do I need an eQMS to manage technical documentation on a small team? No, but most small teams benefit from one past the first year. Clause 4.2.4 of EN ISO 13485:2016+A11:2021 specifies outcomes, not tools. A disciplined shared drive with a controlled document list can satisfy the clause. An eQMS automates the mechanical parts — version history, approval workflow, obsolescence — which reduces the burden on team discipline. The right question is whether your team can maintain discipline with the tool you pick.

How many hours per week does managing a technical file take on a small team? For a Class I or Class IIa startup in active development, expect each section owner to spend two to five hours per week on their sections, plus the 45-minute weekly review meeting for the whole team. The load spikes before design reviews, audits, and formal submissions. The load is manageable because the work is distributed across three owners and paced across the week rather than burst-loaded.

What happens when one of our three people leaves? This is the hardest problem for a small team and the reason single ownership must be paired with documentation that a replacement can actually read. Every owner should be able to hand off their sections with a half-day walkthrough, which is only possible if the sections are structured, named, and version-controlled. If handover would take a month, the file is already broken — the finding has not happened yet, but it will.

Who signs off on the technical documentation on a three-person team? The legal manufacturer per Article 10(4). Inside the company, the person designated under Article 15 as responsible for regulatory compliance (the PRRC) has specific accountability, which for small enterprises may be held by an external partner under Article 15(2) provided the arrangement is continuous. The operations lead is typically the approver for QMS documents; the founder-engineer is typically the approver for design documents; the clinical lead is typically the approver for clinical and intended-purpose documents. Three people, three approval lanes, one accountable manufacturer.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10, paragraph 4 (manufacturer obligation to draw up and keep up to date the technical documentation in accordance with Annexes II and III), Annex II (technical documentation). Official Journal L 117, 5.5.2017.
  2. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Clause 4.2.4 (control of documents).

This post is part of the Technical Documentation and Labeling series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The three-person Lower Austria outcome described here is drawn from Tibor's direct experience working with the company and observing its first Notified Body audit. If your small team is approaching a first audit and wants an outside read on whether the file and the ownership model will survive it, Zechmeister Strategic Solutions runs structured pre-audit reviews sized for startup teams.