---
title: Document Control Under MDR: A Practical ISO 13485-Based System for Small Teams
description: Document control is where most small-team QMS systems break. Here is an ISO 13485 clause 4.2.4-based approach that actually works for MedTech startups.
authors: Tibor Zechmeister, Felix Lenhard
category: Quality Management Under MDR
primary_keyword: document control MDR startup
canonical_url: https://zechmeister-solutions.com/en/blog/document-control-startup
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Document Control Under MDR: A Practical ISO 13485-Based System for Small Teams

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

> **Document control is the QMS process that ensures the right people are using the right version of the right document at the right time, and that obsolete versions cannot be mistaken for current ones. EN ISO 13485:2016+A11:2021 clause 4.2.4 defines what document control must achieve; clause 4.2.3 covers the quality manual and clause 4.2.5 covers records. MDR Article 10(9) makes documented QMS processes a legal obligation. For a small MedTech team, a practical document control system needs a single source of truth, a simple approval workflow, a clear lifecycle with explicit obsolescence, and discipline that survives the first time someone is in a hurry.**

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

---

## TL;DR

- Document control under EN ISO 13485:2016+A11:2021 clause 4.2.4 requires that documents are approved before use, reviewed and updated as needed, changes identified, current versions available at points of use, documents legible and identifiable, external documents controlled, and obsolete documents prevented from unintended use.
- MDR Article 10(9) requires every manufacturer to establish, document, implement, maintain, and keep up to date a QMS. Document control is the mechanical backbone of that obligation.
- Document control (clause 4.2.4), the quality manual (clause 4.2.3), and records (clause 4.2.5) are three distinct clauses. Small teams routinely collapse them into one process and lose audit findings as a result.
- A lean document control system for a startup is one document control procedure, one controlled document list, one approval workflow, and one tool that enforces versioning. Anything more is usually waste; anything less will fail audit.
- The failure mode is almost never "too few documents." It is obsolete versions on someone's desktop, unapproved drafts in use, and no evidence of who reviewed what when.

---

## Why document control is where small-team QMS systems break

A Vienna QA manager once walked into a startup's office on her first week and asked a simple question: "Where is the current version of the software development plan?" She got four answers from four people. One pointed to a SharePoint folder. One opened a PDF on their laptop. One said "I think Max has the latest." The fourth opened a Git repository and pulled up a markdown file that looked nothing like the other three. Four copies, four versions, no single source of truth, and no way to tell which one governed the work.

That startup was not careless. The founders were competent engineers and the QA hire was experienced. What they had failed to build — because nobody had told them it needed building first, before anything else — was document control. And because document control was missing, nothing else in the QMS could work. Design controls referenced procedures nobody could locate. CAPA records pointed to policy documents that had been superseded three times. Training records claimed people had read versions that no longer existed.

This is the pattern. Document control is the unglamorous spine of the QMS. When it is missing, every other process inherits the chaos. When it is solid, every other process has something to stand on. The difference between a QMS that passes audit and a QMS that produces a Berlin-style 0.1 percent assessment is almost never a missing procedure. It is a document control system that never existed, or one that existed on paper but was not enforced.

## What EN ISO 13485:2016+A11:2021 clause 4.2.4 actually requires

EN ISO 13485:2016+A11:2021 is the harmonised standard for medical device QMS and the tool of choice for meeting MDR Article 10(9). Clause 4.2.4 is the document control clause, and it sets out a specific list of things the QMS must do for every document required by the QMS.

Documents must be approved for adequacy before issue. Documents must be reviewed, updated as necessary, and re-approved. Changes and the current revision status must be identified. Relevant versions of applicable documents must be available at points of use. Documents must remain legible and readily identifiable. Documents of external origin (standards, regulations, supplier documentation) that the organisation determines to be necessary must be identified and their distribution controlled. The unintended use of obsolete documents must be prevented, and suitable identification must be applied if they are retained for any purpose.

That is the list. Every word is load-bearing. "Approved before issue" means draft documents in active use are a non-conformity. "Current revision status identified" means the version number and approval date must be on the document. "Available at points of use" means if a procedure governs a process, the people running the process must be able to see it when they run it. "Obsolete documents prevented from unintended use" means old versions on laptops and shared drives are a non-conformity regardless of intent.

Clause 4.2.4 also requires a documented procedure that defines the controls needed — meaning document control is itself a controlled process with its own procedure.

Two related clauses live nearby. Clause 4.2.3 covers the quality manual: every QMS must have one, and it must describe the scope of the QMS, reference the documented procedures, and describe the interactions between QMS processes. Clause 4.2.5 covers records: records are a distinct class of controlled document with their own requirements for identification, storage, protection, retrieval, retention, and disposition. Small teams routinely treat documents and records as the same thing. They are not. A procedure is a document. A filled-in design review form is a record. Control requirements overlap but are not identical.

## Version control approaches that actually work at small scale

Version control for QMS documents is where small teams invent creative solutions that later collapse under audit pressure. There are three practical approaches that survive real use in small MedTech teams, and one that does not.

**The document management system approach.** A dedicated eQMS tool (there are several on the market targeted at small MedTech teams) handles versioning, approvals, access control, obsolescence, and audit trail as a managed service. Pros: enforces discipline, produces audit evidence automatically, prevents most common mistakes by design. Cons: monthly cost, learning curve, and a tendency to become another silo if nobody owns it. For most funded MedTech startups past seed, this is the right answer. Choose a tool that is used by companies of your class and size, not the tool with the most features.

**The Git-as-document-control approach.** For software-heavy startups where the engineering team already lives in Git, QMS documents can be kept as markdown files in a version-controlled repository with a pull request workflow for approvals. Pros: the engineers use the tool they already know, the version history is immutable, and approvals are explicit through PR reviews. Cons: the rest of the team (QA lead, external PRRC, non-technical founders) may never fully adopt it, and the audit trail needs explicit configuration to satisfy an auditor who does not read Git log. This works when the whole team is technical. It fails when it is not.

**The structured shared drive approach.** A disciplined folder structure on a shared drive (Google Drive, SharePoint, Nextcloud) with a naming convention that embeds version numbers and approval status, plus a controlled document list maintained as a spreadsheet, plus a rule that only PDFs of approved documents live in the "effective" folder while working drafts live elsewhere. Pros: cheap, simple, familiar. Cons: relies entirely on discipline, and discipline decays. This can work for a three-person team in the first year if the discipline is real. It fails the moment the team grows to six and nobody formalised the rules.

**The approach that does not work: email and personal laptops.** Documents attached to emails, stored on individual laptops, sent around as "latest version" with no single authoritative copy. This is not version control. It is what happens when nobody has built version control. Every small team starts here by accident. The job of the first QA hire or the first regulatory sparring session is to get the team out of this state before the first document control audit finding is inevitable.

Whichever approach you choose, the test is the same: can you, right now, produce the current approved version of any QMS document in under sixty seconds, and can you prove to an auditor who the previous version was, who approved the change, when, and why?

## Approval workflow for small teams

Clause 4.2.4 requires documents to be approved for adequacy before issue and re-approved after changes. For a large company, this is a multi-layer sign-off with defined roles. For a small team, the same requirement applies but the roles collapse.

The practical minimum approval workflow for a startup has three roles: author, reviewer, and approver. These can be (and often are) only two or three people in total — but they must be three distinct acts, not one person clicking through their own draft. The author drafts. The reviewer reads and challenges. The approver signs off after the review is addressed. The signatures and dates are recorded, either in the document itself or in the document management system.

For very small teams, the founder or CEO frequently ends up as approver for most QMS documents. That is legitimate, but it means the founder actually has to read the document before approving it. An approver who signs without reading is not an approver — they are a rubber stamp, and auditors can tell the difference by asking the approver one question about the document's content.

The approver for document control itself (the procedure that governs all other approvals) should be top management, because clause 4.2.4 is tied to management responsibility. This is one of the few places where it is worth having the CEO's name on the document.

For technical documents where the author has the deepest expertise, the reviewer can be an external sparring partner (fractional QA lead, regulatory consultant) rather than an internal second engineer. External review is legitimate under the standard as long as the reviewer is competent and the review is genuine.

The workflow must be written down in the document control procedure. Not "documents are reviewed" — the procedure must specify who approves what class of document, what happens when a reviewer disagrees with an author, how re-approval is triggered after a change, and how the approval is recorded.

## Document lifecycle: draft, effective, obsolete

Every QMS document moves through three states, and the document control system must handle each transition explicitly.

**Draft.** The document is being written or revised. It is clearly marked as draft. It is not used to govern any process. It lives in a location distinct from effective documents so that nobody mistakes it for one. A draft must never be printed and posted on a wall, never referenced in a training record, never linked from a CAPA. The most common small-team mistake is treating a "pretty close to final" draft as effective because the team is in a hurry. Clause 4.2.4 does not permit this.

**Effective.** The document has been reviewed, approved, assigned a version number and effective date, and issued. It is the authoritative version for the process it governs. Everyone who needs it can find it. Training on the new version (where training is required) has happened or is scheduled. This is the state where most of the document's life is spent.

**Obsolete.** The document has been superseded by a new version or retired entirely. Clause 4.2.4 requires that obsolete documents be prevented from unintended use. In practice this means they are moved out of the active location, marked clearly as obsolete, and retained (if retained at all) in a separate archive for historical and regulatory purposes. The retention period for obsolete QMS documents should be defined in the document control procedure and must meet any applicable regulatory retention requirements for the device's lifetime plus a defined period.

The transition between states is where audit findings come from. A document that went from draft to effective without a recorded approval is a finding. An obsolete document still present in the effective folder is a finding. A current version the team cannot locate is a finding. The lifecycle is not a bureaucratic formality. It is the mechanism by which the QMS stays honest about which version of which process is running the company.

Records (clause 4.2.5) have a slightly different lifecycle: they are created, stored, retained, and eventually disposed of according to a retention schedule. Records are not approved and re-approved the way controlled documents are — a record is a trace of a process running, not a governing document. Keep the two classes separate in your mental model and in your file structure.

## Tools versus discipline

A good tool does not replace discipline, and discipline can (for a small enough team) partially replace a tool. But neither alone is sufficient.

The tool (whatever you choose) enforces the parts of document control that benefit from automation: immutable version history, access control, forced approval before issue, audit trail of who did what when. The tool cannot make a lazy reviewer read a document, cannot make an author write honestly about a process, and cannot prevent a tired founder from clicking "approve" without thinking.

Discipline handles the parts the tool cannot: the author writing the procedure to match real work, the reviewer pushing back when the draft is wrong, the approver reading before signing, the team actually using the current version at the point of use, the obsolete version actually being removed from laptops and bookmarks.

The right split for a small MedTech team is: pick the simplest tool that enforces the mechanical requirements of clause 4.2.4, and put the team's discipline into the parts the tool cannot handle. A startup that picks an elaborate tool and no discipline produces a beautiful audit trail for a dishonest QMS. A startup that picks no tool and tries to run on discipline alone produces a chaotic shared drive that fails the first audit. The combination is what works.

## Common mistakes

Five mistakes account for the overwhelming majority of document control non-conformities we see in small MedTech teams.

First, **no single source of truth.** Multiple copies of the same document live in different places, and nobody can say which one is authoritative. Fix: one location, one version, enforced.

Second, **draft documents in active use.** Something "close to final" is being followed because the team needed to start the process. Fix: if the process is running, the document governing it must be effective. If the document is still draft, the process is not yet running under the QMS.

Third, **approval without review.** The approver signed without reading. Fix: three distinct roles, and an approver who can defend the document in an audit.

Fourth, **obsolete versions on personal devices.** The new version was issued but the old one is still open on three laptops and bookmarked in two browsers. Fix: an explicit obsolescence step that removes old versions from active locations and a team habit of never bookmarking a specific version URL.

Fifth, **the quality manual is missing, out of date, or disconnected from the actual procedures.** Clause 4.2.3 is not optional and the quality manual must describe the QMS as it actually exists. Fix: treat the quality manual as a living document and update it whenever a process changes, not once a year before audit.

## The Subtract to Ship angle

Document control is where the [Subtract to Ship framework](/blog/subtract-to-ship-framework-mdr) earns its name at the QMS level. The default startup mistake is to build a document control procedure modelled on a 500-person pharmaceutical company and then fail to run any of it. The Subtract to Ship version: the document control procedure is one document, two or three pages, that describes exactly the workflow the team actually uses. The controlled document list is one spreadsheet or one table in the document management system. The approval roles are the minimum that clause 4.2.4 allows. Every element of the system traces to a specific requirement of clause 4.2.4, clause 4.2.3, clause 4.2.5, or MDR Article 10(9).

What gets cut: multi-layer approval workflows nobody follows, quarterly document review cycles that produce no changes, template library sections for document classes that do not exist in the company, sign-off matrices designed for functional departments that have not been hired. What stays: the mechanics of clause 4.2.4, every one of them, enforced.

## Reality Check — Where do you stand?

1. Right now, can you point one person — not three — to the current approved version of your most critical QMS procedure in under sixty seconds?
2. If an auditor asked who approved the last revision of your software development plan, when, and why, could you produce the evidence?
3. Does your team know the difference between a draft, an effective document, and an obsolete one, and does your storage location make the distinction visible?
4. When a document is superseded, is the old version actually removed from active locations, or does it linger on laptops and bookmarks?
5. Is your document control procedure itself approved, versioned, and under its own control?
6. Does your quality manual (clause 4.2.3) describe the QMS as it actually exists today, or the QMS you intended to build a year ago?
7. Are records (clause 4.2.5) and controlled documents (clause 4.2.4) handled as two distinct classes in your system, or collapsed into one?

## Frequently Asked Questions

**What does ISO 13485 clause 4.2.4 require for document control?**
Clause 4.2.4 of EN ISO 13485:2016+A11:2021 requires that documents are approved before issue, reviewed and updated as needed and re-approved, that changes and current revision status are identified, that relevant versions are available at points of use, that documents remain legible and identifiable, that external documents are controlled, and that obsolete documents are prevented from unintended use. A documented procedure defining these controls is also required.

**Do I need a dedicated eQMS tool for document control as a startup?**
Not strictly. Clause 4.2.4 does not name a tool. It names outcomes. A small team can meet the requirements with a disciplined shared drive and a well-maintained controlled document list, or with a Git-based workflow if the whole team is technical. A dedicated eQMS makes the mechanics easier and the audit trail automatic, which is usually worth the cost by the time the team reaches six or seven people.

**What is the difference between clause 4.2.4 and clause 4.2.5?**
Clause 4.2.4 controls documents — the governing procedures, work instructions, specifications, and plans that tell people how to run processes. Clause 4.2.5 controls records — the evidence produced as those processes run. Documents are approved, versioned, superseded. Records are created, stored, retained, disposed. Different lifecycle, different controls, same QMS.

**Can I use Google Drive for document control under MDR?**
Yes, if the implementation enforces the requirements of clause 4.2.4. That means approved versions in a clearly defined location, obsolete versions removed from active use, version history preserved, approval recorded, and a controlled document list that keeps the whole system queryable. Google Drive alone does not enforce these things — your procedure and your discipline do. Many small startups pass audits with a well-run shared drive. Many more fail audits with a poorly run one.

**How many documents does a lean document control system need?**
One documented document control procedure (required by clause 4.2.4 itself), one controlled document list (or equivalent index), and whichever templates the team actually uses for the document classes that exist in the company. Do not create template documents for processes you do not run. Do not create approval matrices for roles you do not have. The system should be the smallest one that satisfies every sub-requirement of clause 4.2.4.

## Related reading

- [What Is a Quality Management System for Medical Devices?](/blog/what-is-quality-management-system-medical-devices) — the hub post for the QMS cluster and the clause-by-MDR-article orientation this post inherits.
- [How to Build a Lean QMS for Your MedTech Startup](/blog/build-lean-qms-mdr-startup) — the seven-step method for building the QMS this document control system sits inside.
- [The Minimum Viable QMS for Early-Stage MedTech](/blog/minimum-viable-qms) — what the smallest legitimate Class I QMS actually contains.
- [Records Management Under MDR and ISO 13485](/blog/records-management-mdr-iso-13485) — the companion post on clause 4.2.5 and the distinction between documents and records.
- [Change Control Under MDR](/blog/change-control-mdr) — how document control integrates with QMS change control when a procedure needs to evolve.
- [Internal Audits Under MDR](/blog/internal-audits-mdr) — how internal audits test whether document control is actually being followed.
- [Common QMS Audit Non-Conformities](/blog/common-qms-audit-nonconformities) — the findings document control is supposed to prevent.
- [Training Records Under MDR](/blog/training-records-mdr) — how training on new document versions ties into document control.
- [The Subtract to Ship Framework for MDR](/blog/subtract-to-ship-framework-mdr) — the overarching methodology behind the lean document control system.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10, paragraph 9 (quality management system requirement, proportionate to risk class and type of device). 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.3 (quality manual), clause 4.2.4 (control of documents), clause 4.2.5 (control of records).

---

*This post is part of the Quality Management Under MDR series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. If your document control system is held together by discipline and hope and you are six months from a first Notified Body audit, Zechmeister Strategic Solutions works with founders on reality-matched QMS builds that survive audit without drowning the team in paperwork.*

---

*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).*