---
title: How to Keep Technical Documentation Up to Date: The Lifecycle Approach
description: Technical documentation under MDR is a living file, not a one-shot submission. Here is the lifecycle approach that keeps it audit-ready year after year.
authors: Tibor Zechmeister, Felix Lenhard
category: Technical Documentation & Labeling
primary_keyword: technical documentation lifecycle update
canonical_url: https://zechmeister-solutions.com/en/blog/technical-documentation-lifecycle-update
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# How to Keep Technical Documentation Up to Date: The Lifecycle Approach

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

> **Technical documentation under MDR is a living file, not a one-shot submission. MDR Article 10(4) of Regulation (EU) 2017/745 requires manufacturers to draw up and keep up to date the technical documentation set out in Annex II and Annex III for as long as the device is on the market. Keeping it current means wiring three feedback loops into the QMS: post-market surveillance data flowing back into the file under Article 83, design and manufacturing changes flowing through document control under EN ISO 13485:2016+A11:2021, and regulatory changes (new MDCG guidance, updated harmonised standards, new transitional provisions) flowing through a scheduled regulatory watch. A file that is updated only when the auditor announces themselves is a file that has already failed.**

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

---

## TL;DR

- MDR Article 10(4) imposes an ongoing duty to keep the technical documentation current, not a one-time obligation to compile it for the initial submission.
- Updates are triggered by three distinct sources: post-market surveillance and vigilance data (Article 83 and Annex III), design and manufacturing changes under document control, and regulatory or standards changes that affect the file's conformity argument.
- A lifecycle cadence combines event-driven updates (triggered by specific inputs) with scheduled reviews (annual, quarterly for high-risk sections).
- Significant changes to the device or the intended purpose trigger Notified Body notification obligations. Not every update is significant, but every update has to be evaluated for significance and the evaluation has to be recorded.
- The QMS under EN ISO 13485:2016+A11:2021 is the machinery that makes lifecycle updates reliable. Without document control, the file drifts and the drift is invisible until audit day.

---

## The file is never finished

The first audit is not the finish line. It is the starting line for the part of the technical documentation work that most startups underestimate. Tibor has watched it many times. A team ships the file, passes the audit, exhales, and treats the technical documentation as something that has been "done." Two years later the surveillance audit arrives and the file looks like a museum exhibit — the device described in Section 1 no longer matches the device on the market, the supplier list in Section 3 is missing the two vendors added since launch, the GSPR checklist in Section 4 points to a standard edition that has been superseded, and the PMS file has a plan but no evidence that the plan actually ran.

Against that, the Lower Austria three-person company from earlier posts in this cluster. Their first audit came in with zero nonconformities on technical documentation. What made the second audit equally clean was not luck. It was a lifecycle discipline built into the QMS from the week the file was first released. PMS data arrived on a schedule and was logged against the file. Every engineering change ticket closed against a documented impact assessment on the tech file. A regulatory watch checked harmonised standards and MDCG publications on a quarterly cadence. The file in year two looked almost unrecognisable compared to the file in year zero — because the device had evolved, the data had accumulated, and the discipline had captured all of it.

The difference between those two outcomes is not size, budget, or sophistication. It is whether the team treats the technical documentation as a project that ends at submission or as a process that runs for the life of the device.

## Why technical documentation is a lifecycle obligation

The legal basis for the lifecycle reading sits directly in the text of the Regulation.

> *"Manufacturers of devices other than custom-made devices shall draw up and keep up to date technical documentation for those devices. The technical documentation shall be such as to allow the conformity of the device with the requirements of this Regulation to be assessed. The technical documentation shall include the elements set out in Annexes II and III."* — Regulation (EU) 2017/745, Article 10, paragraph 4.

The phrase "keep up to date" is the lifecycle obligation. It is not optional, and it is not bounded to the period before the first certificate is issued. For as long as the device is on the market — and for the retention period afterwards under Article 10(8) — the file has to represent the current reality of the device, the current state of the evidence, and the current state of the conformity argument.

The PMS side of the file is explicit about the feedback loop. Article 83 of Regulation (EU) 2017/745 requires every manufacturer to plan, establish, document, implement, maintain and update a post-market surveillance system proportionate to the risk class and appropriate for the type of device. Annex III specifies the PMS technical documentation. The words "maintain and update" are not decorative — they are the obligation to let real-world data change what the file says about the device. A file that claims benefits and residual risks from 2024 evidence while the market has produced 2026 data that contradicts it is a file that has failed its own PMS obligation.

EN ISO 13485:2016+A11:2021 is the harmonised standard that provides presumption of conformity with the MDR QMS obligations. It specifies document control, record control, change control, and management review. These are not bureaucracy for its own sake. They are the machinery by which the technical file stays aligned with reality. A QMS that does not update the technical file when the underlying documents change is a QMS that exists on paper only.

## Update triggers from PMS, PMCF, and changes

Lifecycle updates are driven by three categories of trigger. A healthy file knows which category any given change falls under, routes it through the correct procedure, and documents the outcome.

**PMS and vigilance inputs.** Complaints, field reports, incident data, trend analysis, vigilance reports, and PSUR or PMS report findings all feed back into the file. A new complaint pattern that changes the residual risk picture flows into Section 5 (benefit-risk and risk management). A PMCF finding that strengthens or weakens a clinical claim flows into Section 6 (verification and validation, including the clinical evaluation report). A vigilance signal that reveals a hazard the risk file did not anticipate flows into both Section 5 and the design side of Section 3. The PMS plan under Annex III is the document that says how these inputs will be captured and routed. The technical file is the document that has to reflect the conclusions.

**Change control on design and manufacturing.** Every design change and every manufacturing change is an event the file has to absorb. A firmware release. A new supplier qualified for a critical component. A material change in a moulded part. A process change on a sterilisation cycle. A label revision. Each one goes through the change control procedure under EN ISO 13485:2016+A11:2021, each one includes an impact assessment on the technical documentation, and each one closes only when the affected sections of the file have been updated and re-approved. A change that closes in engineering but not in the file is a change that creates a drift.

**Regulatory and standards updates.** The regulatory environment does not stand still. Harmonised standards are updated — for example, the amendment cycles on EN ISO 13485, EN ISO 14971, EN 60601-1, or the newer EN ISO 10993-1:2025. MDCG publishes new guidance and revises old guidance. Transitional provisions change. A file that cited the standard edition that was current at first certification may be citing a superseded edition two years later, and the conformity argument based on that citation is weaker than it looks. A scheduled regulatory watch — quarterly is a reasonable baseline for most startups — catches these before an auditor does.

## The routine update cadence

Event-driven updates catch the changes that announce themselves. A scheduled cadence catches the drift that does not.

A workable baseline cadence for a resource-constrained team:

- **Weekly.** The PMS inbox is reviewed. Complaints, field feedback, and incoming data are logged against the PMS plan. Anything that looks like a potential signal is escalated immediately rather than waiting for the next scheduled review.
- **Monthly.** Open change requests that affect the technical file are reviewed. Any change that closed in the previous month without the corresponding file update is caught and closed out. The GSPR checklist is spot-checked for broken cross-references where documents have been re-versioned.
- **Quarterly.** A regulatory watch pass. New or revised MDCG guidance, updated harmonised standards, changes to transitional provisions. Each hit is logged with an assessment of whether the file is affected and what update is needed. Section 4 (GSPR checklist), Section 5 (risk management), and Section 6 (verification and validation, clinical evaluation) are reviewed against the PMS data accumulated in the quarter.
- **Annually.** A full technical documentation review. Every section of Annex II is walked through against the current state of the device and the current state of the evidence. The PMS report or PSUR (depending on class) is prepared using the year's accumulated data. The benefit-risk determination is refreshed. The clinical evaluation report is updated per the plan. Management review under EN ISO 13485:2016+A11:2021 takes the outputs.

Higher-risk devices run the quarterly loop on shorter intervals and the annual loop with more depth. Lower-risk devices can run the same structure at a lighter touch, but the structure is the same. What does not work is skipping the cadence and hoping event-driven updates catch everything.

## Notified Body notification triggers

Not every update to the technical file is a change the Notified Body has to be told about in advance. Some are. Getting this distinction right is essential and is one of the places where expert judgment usually earns its keep.

Under the MDR and the Notified Body's specific certificate conditions, manufacturers are required to notify the Notified Body of significant changes to the device design or intended purpose, and to the approved quality management system, before those changes are implemented. "Significant" is the operative word. A typo correction in the IFU is not significant. A new indication for use is. A firmware update that changes a control algorithm in a way that affects the benefit-risk analysis is. A supplier change on a commodity component is generally not — unless the component is critical or the new supplier's qualification data differs meaningfully from the previous one.

The rule we apply: every change that updates the technical file receives an impact assessment that explicitly answers the significance question. The assessment is documented. The outcome — "significant, notify Notified Body" or "not significant, update under internal change control only" — is recorded with the reasoning. This does two things. It catches significant changes before they ship, and it produces the paper trail that protects the manufacturer if the Notified Body later disagrees with a judgement call.

The cost of missing a notification is not a minor finding. It can trigger suspension of the certificate. The cost of over-notifying is friction and Notified Body fees, but no regulatory risk. When in doubt, notify. When judgment says the change is clearly not significant, document the judgment.

## The document control link

None of the lifecycle discipline works without document control that actually functions. This is where EN ISO 13485:2016+A11:2021 earns its place. Every document in the technical file has a controlled number, a version, a status, an owner, a review cycle, and a change history. Every change goes through an approval workflow. Every superseded version is retained for the legally required period. Every cross-reference in the GSPR checklist in Section 4 points to a document identifier that does not change when the document is re-versioned.

The common failure is a "document control system" that is a shared folder with filenames containing the word "final." Version drift sets in within weeks. Cross-references break invisibly. Two people update the same document in parallel and neither update is fully integrated. By the second surveillance audit, nobody on the team can say with certainty which version of which document is the current one. A [proper document control setup for MDR under EN ISO 13485](/blog/document-control-mdr-version-control) is the cheapest insurance against this failure mode.

## Common mistakes in lifecycle updates

- **Treating the file as "done" after the first certificate.** The most common and most expensive mistake. The file drifts, the surveillance audit finds the drift, remediation costs more than continuous maintenance would have.
- **PMS data that does not reach the technical file.** Complaints are logged in a CRM, incidents are reported via the vigilance system, but neither flow produces updates to Section 5 or Section 6. The PMS plan exists, the PMS evidence is missing.
- **Change control that closes in engineering but not in the file.** The engineering ticket is marked done, the design file is updated, the technical documentation is not. The mismatch is invisible until it is not.
- **No regulatory watch.** The team assumes standards and guidance do not change. They do. A file citing a superseded standard is a weaker file.
- **Significance assessments done verbally or not at all.** A change is judged "not significant" in a hallway conversation and nothing is written down. Six months later nobody remembers who decided what on what basis.
- **Annual review that becomes a fire drill.** The annual review is scheduled but the team only actually does it a week before the surveillance audit. The result is a reconstruction exercise, not a review.
- **Cross-references maintained only during the initial build.** After launch, the GSPR checklist is not re-walked and references silently rot as documents are re-versioned.

## The Subtract to Ship angle

The lifecycle discipline looks like addition — more reviews, more scheduled tasks, more procedures. Applied through [the Subtract to Ship framework for MDR](/blog/subtract-to-ship-framework-mdr), it is actually a subtraction move. The alternative to continuous, lightweight maintenance is an episodic scramble every audit cycle, and the scramble costs more in time, money, and risk than the maintenance does. Continuous updates are the cheaper path, not the more expensive one.

Subtraction applies to the cadence itself. Weekly, monthly, quarterly, annual — each loop does only the work that belongs at that frequency and nothing else. A weekly loop that tries to do the annual review's job becomes noise. An annual loop that tries to do the weekly loop's job misses the signals. Each cadence carries its own scope, and the scope earns its place by tracing to a specific obligation — PMS inputs under Article 83, change control under document control, regulatory watch under Annex II Section 4, management review under EN ISO 13485:2016+A11:2021.

## Reality Check — Where do you stand?

1. When was the last time your technical documentation was updated on the basis of PMS data, and is the update traceable to the specific incoming data that triggered it?
2. For every design or manufacturing change made in the last six months, can you point to the corresponding update in the technical file, or the documented assessment that no update was needed?
3. Do you have a scheduled regulatory watch, and when did it last produce a file update?
4. For every change since the last audit, is there a documented significance assessment with the reasoning?
5. Is every cross-reference in the GSPR checklist in Section 4 resolvable today to a document that exists at the cited version?
6. Does the benefit-risk statement in Section 5 reflect the PMS data accumulated since the last review, or is it the version from the first submission?
7. If the surveillance auditor arrived tomorrow, how much reconstruction work would stand between you and a clean file?

## Frequently Asked Questions

**How often does the technical documentation have to be updated?**
There is no single frequency mandated by the MDR. Article 10(4) requires the file to be kept up to date as long as the device is on the market. In practice, this means event-driven updates whenever a PMS input, a design change, or a regulatory change affects the file, plus a scheduled cadence (typically weekly PMS review, monthly change control review, quarterly regulatory watch, annual full review) to catch drift that does not announce itself.

**Does every PMS complaint trigger a technical file update?**
No. Every PMS input is logged and evaluated, but only those that change the risk picture, the benefit-risk determination, the clinical evidence, or the design flow into a file update. The evaluation and its outcome are documented either way, which is itself a record required by the PMS plan under Annex III.

**When do I have to tell the Notified Body about a change?**
Significant changes to the device design or intended purpose, and significant changes to the approved QMS, must be notified before implementation per the general MDR obligation and the specific conditions on your certificate. Non-significant changes are handled under internal change control only. Every change receives a documented significance assessment so the distinction is visible and defensible.

**What happens if my file is out of date at a surveillance audit?**
You receive nonconformities, typically structural ones — out-of-date GSPR references, PMS data not reflected in the file, superseded standards cited, unexecuted changes. Depending on severity, the findings can be minor (addressed via CAPA) or major (requiring closure before the certificate stays in force). Continuous maintenance avoids all of this.

**Can a small team realistically run a lifecycle update cadence?**
Yes. The Lower Austria three-person example in [the technical documentation hub post](/blog/technical-documentation-under-mdr) is one of several we have worked with. The discipline is more important than the headcount. A disciplined three-person team runs a cleaner lifecycle than a disorganised thirty-person team, every time.

## Related reading

- [Technical Documentation Under MDR: What It Is and Why Startups Get It Wrong](/blog/technical-documentation-under-mdr) — the pillar post for this cluster.
- [MDR Annex II: The Structure of Technical Documentation Explained](/blog/mdr-annex-ii-structure) — the section-by-section map your updates have to land on.
- [MDR Annex III: Post-Market Surveillance Technical Documentation](/blog/mdr-annex-iii-pms-technical-documentation) — the PMS side of the file that feeds the lifecycle loop.
- [How to Build Technical Documentation from Day One as a Startup](/blog/build-technical-documentation-from-day-one) — the Phase 1 and Phase 2 discipline that makes lifecycle updates possible later.
- [How to Run Change Control on the Technical File](/blog/technical-file-change-control) — the change-control mechanics behind every design and manufacturing update.
- [How to Run an Internal Review of the Technical Documentation](/blog/technical-documentation-internal-review) — the annual review in detail.
- [Technical Documentation for Software Updates Under MDR](/blog/technical-documentation-software-updates) — the special case of firmware and software release cycles.
- [When a Change Triggers Notified Body Notification](/blog/notified-body-notification-triggers) — the significance assessment mechanics in depth.
- [The Most Common Technical Documentation Gaps in Startup Audits](/blog/common-tech-doc-gaps-startup-audits) — the findings a lifecycle discipline prevents.
- [How to Run a Regulatory Watch for MDR](/blog/mdr-regulatory-watch) — the quarterly standards and guidance review loop.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology behind lean lifecycle maintenance.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10(4) (obligation to draw up and keep up to date the technical documentation as set out in Annexes II and III), Article 83 (post-market surveillance system), Annex II (technical documentation), Annex III (technical documentation on post-market surveillance). Official Journal L 117, 5.5.2017.
2. EN ISO 13485:2016 + A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. The harmonised standard specifying document control, change control, record control, and management review that the lifecycle discipline runs on.

---

*This post is part of the Technical Documentation & Labeling series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. Tibor has seen both the clean surveillance audit that follows a disciplined lifecycle and the reconstruction scramble that follows neglect. The difference is not resources. The difference is whether the file is treated as a project that ends or a process that runs.*

---

*This post is part of the [Technical Documentation & Labeling](https://zechmeister-solutions.com/en/blog/category/technical-documentation) 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).*