Document control under MDR is the process that binds version, approval, and distribution into a single auditable chain: the right version of the right document, approved by the right person, reaching the right people at the right time, with obsolete copies removed from use. EN ISO 13485:2016+A11:2021 clause 4.2.4 defines the specific controls. MDR Article 10 makes the underlying QMS a legal obligation. The three pillars — version, approval, distribution — cannot be separated. A strong version scheme with a broken distribution list still fails audit. A clean approval workflow that publishes to nowhere still fails audit. The chain is only as strong as its weakest link.

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 has three inseparable pillars: version control, approval, and controlled distribution. Each pillar fails in isolation.
  • MDR Article 10 obliges every manufacturer to operate a documented QMS. Document control is the mechanical layer that makes every other QMS process trustworthy.
  • A version number alone is not version control. The scheme must distinguish major from minor changes, carry an approval date, and prevent two documents from sharing the same identifier.
  • An approval workflow must have at least three distinct acts — author, reviewer, approver — even when only two or three people run the company. One person clicking through their own draft is not approval.
  • Controlled distribution means relevant versions are available at points of use and obsolete versions are prevented from unintended use. Printing a copy and losing track of it is a controlled-distribution failure.

Why version, approval, and distribution belong in one chain

A founder once showed an auditor three copies of the same work instruction. The first lived in the shared drive, marked version 1.3, approved. The second was a PDF on the production laptop, marked version 1.2, which the operator was actually following. The third was a printout taped to the wall above the workstation, unsigned, undated, and slightly different from both. All three had the same title. Only one was the document the QMS thought was running the process. The other two were ghosts — real enough to drive behaviour, invisible enough to escape the approval workflow.

That is the failure document control is built to prevent. It is not a version-numbering problem, not an approval problem, and not a distribution problem. It is all three at once. The version scheme failed because two numbers were in circulation. The approval workflow failed because the printout on the wall had no approver. The distribution failed because the operator's laptop had a stale copy and nobody had swept it.

Document control under MDR is the single chain that binds those three things together. Break any link and the chain holds nothing.

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

EN ISO 13485:2016+A11:2021 clause 4.2.4 is the document control clause of the harmonised QMS standard, and it is the tool the industry uses to meet the QMS obligation in MDR Article 10. The clause sets out a specific list of things the QMS must do for every controlled document.

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 that the organisation determines to be necessary must be identified and their distribution controlled. The unintended use of obsolete documents must be prevented, and any obsolete documents retained for any reason must be suitably identified.

A documented procedure defining these controls is itself required — document control is a controlled process with its own procedure.

Three of those requirements map directly onto the three pillars of this post. "Approved before issue" is the approval pillar. "Changes and current revision status identified" is the version pillar. "Available at points of use" and "unintended use of obsolete documents prevented" are the distribution pillar. Clause 4.2.4 does not let you pick two out of three.

The three pillars: version, approval, distribution

Version is the answer to the question "which one of these am I looking at?" It is not just a number. A version is a number plus an approval date plus a change history plus a guarantee that no two documents in the system share that identifier. A version that cannot be distinguished from its predecessor by inspecting the document is not a version — it is a name collision.

Approval is the answer to the question "who said this version is fit to govern the process?" It is not a signature on the last page. It is the chain of author, reviewer, and approver that produced the document, recorded with names and dates, surviving staff turnover and storage migration. Clause 4.2.4 requires approval before issue, which means a document that is "basically approved" is a document that is not yet in effect.

Distribution is the answer to the question "does the person running the process right now have this version available, and is the previous version gone from their reach?" Controlled distribution is two operations in one: pushing the current version to every point of use, and pulling every obsolete version out of every point of use. Both operations must happen. A push without a pull leaves ghosts behind.

The three pillars are equally load-bearing. A system with airtight version numbering, rigorous approval, and no controlled distribution is the system the founder above was running. A system with clean distribution but casual approval produces documents nobody trusts. A system with version 1.0 sitting unchanged for three years has no approval activity to audit and no distribution to monitor. All three, or none.

Version naming that survives an audit

Version numbering is where small teams invent schemes that later fail under pressure. Four rules keep a scheme audit-ready.

First, distinguish major from minor changes. A two-part scheme (1.0, 1.1, 2.0) is the minimum. Major version changes indicate substantive revisions that usually require re-training, re-issue to every point of use, and sometimes re-validation of the process the document governs. Minor version changes are corrections that do not alter how the process runs. The procedure must define where the line sits. "We know it when we see it" is not a definition.

Second, no version 0.x in effective use. Pre-1.0 numbering belongs to draft territory. The moment a document becomes effective, it is 1.0 or later. Teams that ship effective documents as "0.9 approved" are muddling the draft and effective states and will lose findings on it.

Third, the version identifier lives on every page. Footer, header, or both. Version, effective date, and document identifier visible without opening metadata. A printed page must be self-identifying, because a printed page lives outside the tool that generated it.

Fourth, no two documents share a version identifier. If a procedure is superseded by a new document with a new scope, the old identifier retires and the new one begins at its own 1.0. Reusing numbers across documents is the single fastest way to corrupt a controlled document list.

Whatever scheme you pick, write it down in the document control procedure and apply it consistently. A consistent simple scheme beats an elegant scheme that nobody follows.

Approval workflow that three people can actually run

Clause 4.2.4 requires approval before issue and re-approval after changes. For a three-person startup, the same requirement applies as for a three-hundred-person company — the roles just collapse onto fewer people.

The practical minimum is three distinct acts: author, reviewer, approver. The author drafts. The reviewer reads critically and pushes back where the draft is wrong. The approver signs off after the review is addressed. For very small teams, author and reviewer may be the only two technical people in the company, and the approver may be the CEO. That is legitimate — as long as the three acts are genuinely distinct. One person approving their own draft is not an approval workflow.

The approval record must include names, dates, and the version being approved. The approval is tied to a specific version, not to the document in general. Every new version triggers a new approval. A revision to a document is not approved because the previous version was approved.

For technical documents where the author holds the deepest expertise, the reviewer can legitimately be an external sparring partner — a fractional QA lead, a regulatory consultant — as long as the review is real and recorded. The standard does not require internal-only review. It requires review.

The document control procedure itself is governed by document control, which means the document control procedure has an approver too. That approver should be top management, because clause 4.2.4 connects document control to management responsibility. The CEO's name on the document control procedure is one of the few places that signature carries specific weight.

Controlled distribution versus uncontrolled distribution

Clause 4.2.4 requires relevant versions of applicable documents to be available at points of use. The word "controlled" in controlled distribution means two things: the current version reaches every location where the process runs, and the organisation knows who has copies.

Controlled copies live at defined points of use, tracked by the document control system, and are updated or replaced when a new version issues. A controlled copy is bound to a distribution list, and the distribution list is part of the record.

Uncontrolled copies are the ones that escape the system — a PDF emailed to a supplier for reference, a printout taken home by an engineer, a screenshot pasted into a Slack thread. Uncontrolled copies are not forbidden, but they must be marked as uncontrolled when they leave the system so that nobody downstream mistakes them for governing documents. A typical marking is a watermark or footer reading "Uncontrolled copy — valid on date of printing only."

The failure mode is the uncontrolled copy that re-enters the system as if it were controlled: the screenshot that gets saved into the QMS folder, the printout that gets tacked to the wall and treated as authoritative, the email attachment that gets forwarded and cited in a design review. Every one of those is a break in the distribution pillar.

For a small startup, controlled distribution is easier than it sounds if the team picks one authoritative storage location and makes everyone go there for the current version. The distribution list is implicit — anyone who needs the document knows the one place to look. The discipline is that no copies exist outside that one place for governing purposes. If someone needs to share a copy externally, it is exported, marked uncontrolled, and noted.

Obsolete document handling

Clause 4.2.4 requires obsolete documents to be prevented from unintended use, and — if retained for any reason — to be suitably identified. Obsolescence is where distribution failures cluster, because it is the quiet half of the work. Issuing a new version is visible. Pulling the old version out of every corner is invisible until an auditor finds a copy.

The minimum obsolete-document workflow has four steps. The new version is approved and issued. The old version is moved out of the active location into an archive. Every controlled copy at every point of use is replaced with the new version, and the old copies are recalled. The old version is marked as obsolete in the archive — a watermark, a status field, or a folder named "obsolete" — so that anyone who accidentally opens it knows it is not in effect.

The retention period for obsolete documents is defined in the document control procedure. For most QMS documents the retention must cover the device lifetime plus the minimums set by clause 4.2.5 on records and the retention obligations in MDR Article 10 for technical documentation. An obsolete document that has been legally destroyed after its retention period is gone. An obsolete document still in the system is never ambiguous — it is marked, or it is a finding.

The single most effective obsolescence habit for small teams is the rule that nobody bookmarks a version-specific URL. Bookmarks go to the document's canonical location, which always serves the current version. When a new version issues, the bookmark still works. The old bookmark problem — the one where an engineer follows a stale link to a superseded procedure for six weeks — simply does not happen.

Common mistakes

Five mistakes account for most version-approval-distribution findings in small MedTech teams.

First, version numbers on effective documents that started at 0.1. The draft numbering leaked into the effective state. Fix: draft numbering never crosses into effective. Version 1.0 is the first effective version.

Second, approval recorded only in email. The approver wrote "approved" in a reply thread and nobody captured it in the document or the tool. Fix: the approval lives with the document, in the form of a signature block, a tool action, or an entry in the controlled document list — not in someone's inbox.

Third, the distribution list that nobody updates. When a new version issues, the team pushes it into the active folder but does not replace the controlled copies at every point of use, because nobody has looked at the distribution list in eight months. Fix: the distribution list is part of the release checklist for every new version.

Fourth, uncontrolled copies that re-enter the QMS. A printout or a PDF export gets treated as authoritative after it left the system. Fix: mark every export as uncontrolled on the way out and never re-ingest an exported copy as a controlled one.

Fifth, obsolete documents still reachable from the active location. The new version went live, but the old version is still in the same folder, one click away. Fix: obsolete documents leave the active location at the moment of issue. Not later.

The Subtract to Ship angle

Document control is where the Subtract to Ship framework earns its keep at the QMS mechanics level. The default startup mistake is to build a document control system modelled on a five-hundred-person pharmaceutical company — nested approval matrices, quarterly document review cycles, a controlled document list with every possible class pre-populated — and then fail to run any of it. The Subtract to Ship version is the opposite: one document control procedure, two or three pages, covering version, approval, and distribution in terms of what the team actually does. One controlled document list. One approval workflow with three distinct roles. One storage location for effective documents. One archive for obsolete versions. Every element traces to a specific sub-requirement of clause 4.2.4 and to MDR Article 10.

What gets cut: elaborate approval hierarchies for roles that do not exist, quarterly reviews that generate no changes, template sections for document classes the company does not produce, distribution lists for locations that are not points of use. What stays: the three pillars, every one, enforced.

Reality Check — Where do you stand?

  1. Can you, right now, open any QMS document and see its version number, effective date, and approval status without opening metadata or asking a colleague?
  2. Does your version scheme distinguish major from minor changes in a way the team can apply without debate?
  3. If you issued a new version this afternoon, would every point of use have the new version and only the new version by end of day?
  4. Are uncontrolled exports of your documents marked as uncontrolled on the way out of the system?
  5. Is every obsolete version of every document either in a clearly marked archive or destroyed — with no stray copies in active locations?
  6. Does the approval workflow have three distinct acts (author, reviewer, approver), even when only two or three people run the company?
  7. Is your document control procedure itself versioned, approved, and distributed under its own rules?

Frequently Asked Questions

What does document control under MDR require for version, approval, and distribution? Document control under MDR rests on EN ISO 13485:2016+A11:2021 clause 4.2.4, which requires documents to be approved before issue, to have their current revision status identified, to be available at points of use in relevant versions, and to be prevented from unintended use when obsolete. MDR Article 10 makes the underlying QMS a legal obligation. Version, approval, and distribution form a single chain — the document control procedure must cover all three.

How should a small MedTech startup number document versions? Use a two-part scheme that distinguishes major from minor changes (1.0, 1.1, 2.0). Start effective documents at 1.0 — draft numbering stays below 1.0 and does not leak into the effective state. Put the version, effective date, and document identifier on every page. Define in the document control procedure what counts as a major versus minor change, and never reuse identifiers across different documents.

Who should approve QMS documents in a three-person startup? At minimum, three distinct acts — author, reviewer, approver — even if the roles sit on only two people. The reviewer can be an external sparring partner such as a fractional QA lead if the technical depth is inside the founder team. The document control procedure itself should be approved by top management, because clause 4.2.4 ties document control to management responsibility.

What is the difference between controlled and uncontrolled distribution? A controlled copy is tracked by the document control system, lives at a defined point of use, and is updated or replaced when a new version issues. An uncontrolled copy is any export that leaves the system — a PDF shared with a supplier, a printout taken off-site. Uncontrolled copies are allowed if they are marked as uncontrolled on the way out, so downstream readers do not mistake them for governing documents.

How do I handle obsolete documents under clause 4.2.4? When a new version issues, move the old version out of the active location into an archive, mark it clearly as obsolete, and recall any controlled copies from points of use. The retention period for obsolete documents is defined in the document control procedure and must meet the longest applicable obligation, including the MDR Article 10 retention period for technical documentation. Obsolete documents that remain reachable from the active location are a finding.

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, including the quality management system obligation). 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 Tibor Zechmeister and Felix Lenhard. If your version, approval, and distribution chain has weak links that nobody has tested under audit pressure, Zechmeister Strategic Solutions works with founders on document control systems that hold together when the Notified Body walks in.