---
title: MDR QMS for Software Companies: Adapting ISO 13485 for Agile Development
description: How to build an EN ISO 13485:2016+A11:2021 QMS for a software-first MedTech startup that runs agile sprints, without burning runway on paper.
authors: Tibor Zechmeister, Felix Lenhard
category: Quality Management Under MDR
primary_keyword: MDR QMS software companies agile ISO 13485
canonical_url: https://zechmeister-solutions.com/en/blog/mdr-qms-software-companies-agile
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# MDR QMS for Software Companies: Adapting ISO 13485 for Agile Development

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

> **An MDR quality management system for a software-first MedTech startup running agile sprints is an EN ISO 13485:2016+A11:2021 QMS with the software lifecycle processes of EN 62304:2006+A1:2015 wired into the design and development clauses, and with the procedures written so the engineering team's existing tooling — issue tracker, git repository, CI pipeline, pull request process — produces the records the standard requires as a by-product of normal work. The QMS is required by MDR Article 10(9), demonstrated against Annex IX for conformity assessment, and the software-specific obligations live under Annex I Section 17. The adaptation move is not to write a parallel bureaucratic system alongside the engineering process — it is to map every clause of ISO 13485 to a place in the engineering workflow where the activity is already happening, and to make the record land where it is made, not in a shared-drive binder.**

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

---

## TL;DR

- MDR Article 10(9) requires every manufacturer to establish, document, implement, maintain, and keep up to date a QMS. EN ISO 13485:2016+A11:2021 is the harmonised standard that provides presumption of conformity for this obligation.
- EN ISO 13485:2016+A11:2021 is process-neutral. A software-first startup running agile sprints can satisfy every clause without running a waterfall project, and without hiring a "QMS team" separate from engineering.
- The adaptation move is mapping, not adding. Every clause of the standard lands on a place in the engineering workflow — sprint planning, pull requests, CI pipeline, release decisions, incident response — where the activity already happens.
- The software-specific clauses of EN 62304:2006+A1:2015 slot under EN ISO 13485:2016+A11:2021 clause 7.3 as the software lifecycle model, with clauses 4, 5, 6, 8, and 9 of ISO 13485 providing the QMS frame around them.
- Records live in the repository, not in a shared-drive binder. The auditor reads what the engineers actually produced, not a retroactive reconstruction.
- MDCG 2019-11 Rev.1 applies when the software itself qualifies as a medical device (MDSW) — the QMS scope has to name the MDSW boundary explicitly.
- The failure mode is running two systems in parallel — one for engineering, one for "quality" — which drift apart and fail audit. The fix is one system, with the engineering workflow as the backbone.

---

## Why software founders think ISO 13485 was written for someone else

The first time a software founder opens EN ISO 13485:2016+A11:2021, the reaction is almost always the same. The standard talks about production environments, sterilisation, installation, servicing, particulate contamination, and cleanroom hygiene in a way that sounds like it was written for a factory making surgical implants. The founder flips through, sees clause 6.4 on work environment and clause 7.5.2 on cleanliness of product, and concludes this standard has nothing to do with shipping a web application that runs risk stratification on ICU data.

The conclusion is wrong. The standard is written to cover the full range of medical devices, which means many clauses carry a "where applicable" qualifier that the software-first manufacturer reads, documents the non-applicability of, and moves on. What is left after the non-applicable clauses are scoped out is a QMS backbone — management responsibility, resource management, product realisation, measurement and improvement — that absolutely does apply to a software company and that has to be documented, implemented, and maintained under MDR Article 10(9).

The harder realisation is that the backbone is not the enemy. Most of what EN ISO 13485:2016+A11:2021 requires at the backbone level is what a competent software team already does — version control, change authorisation, peer review, testing, incident response, supplier evaluation, training records — just with different names and a different level of formality. The adaptation is not a transplant. It is a relabelling exercise, done with discipline, wired into the tooling the team already uses.

## What MDR Article 10(9) actually obliges

Under MDR Article 10(9), manufacturers of medical devices shall establish, document, implement, maintain, keep up to date, and continually improve a quality management system that shall ensure compliance in the most effective manner and in a manner proportionate to the risk class and the type of device. (Regulation (EU) 2017/745, Article 10, paragraph 9.) The article then lists the aspects the QMS shall address, including a strategy for regulatory compliance, identification of applicable GSPRs, responsibility of management, resource management, risk management, clinical evaluation, product realisation, verification of the UDI assignment, post-market surveillance, communication with authorities and notified bodies, processes for reporting of serious incidents and FSCAs, and management of corrective and preventive actions.

The conformity assessment route for most software devices under MDR runs through Annex IX, where the notified body audits the QMS against the standard. (Regulation (EU) 2017/745, Annex IX.) EN ISO 13485:2016+A11:2021 is the harmonised standard that provides presumption of conformity with the QMS obligations of Article 10(9). A manufacturer who follows EN ISO 13485:2016+A11:2021 in a scoped, justified way is on the safest path through the audit.

For software that itself qualifies as a medical device — MDSW — classification under Annex VIII Rule 11 drives the notified body involvement, and the QMS scope has to name the MDSW product and its intended purpose explicitly. MDCG 2019-11 Rev.1 is the guidance that governs MDSW qualification and classification and should be referenced in the QMS manual. (MDCG 2019-11 Rev.1, June 2025.)

## Mapping the ISO 13485 clause structure onto an agile software team

The adaptation is mechanical once the mapping is laid out. Each clause of EN ISO 13485:2016+A11:2021 lands on a place in the software team's existing workflow, with the records produced where the work happens.

Clause 4 (QMS and documentation requirements) maps to a lean QMS manual plus the document and record control discipline applied to the repository. The manual is ten to twenty pages, names the scope, the processes, and the mapping to the standard's clauses. Document control runs through git — versioning, history, change authorisation via pull request, retention by repository backup. Record control runs the same way for engineering records and through a ticketing system for management and regulatory records.

Clause 5 (management responsibility) maps to the founder-CEO and the leadership team running management reviews on a defined cadence, with documented inputs and outputs. For a ten-person startup, the management review is a real meeting on a real cadence with minutes and an action list — not a ceremony invented for the auditor.

Clause 6 (resource management) maps to training records, competence matrices, and — for software-only devices — a stripped-down work environment and infrastructure procedure that covers the development environment, the CI infrastructure, the hosting infrastructure, and the access controls. Clauses about cleanliness of product and particulate contamination are scoped out with a documented justification.

Clause 7 (product realisation) is the core of the software adaptation. Clause 7.1 planning, clause 7.2 customer-related processes, and clause 7.3 design and development are where the agile workflow lives. EN 62304:2006+A1:2015 provides the software lifecycle model that runs inside clause 7.3. Clause 7.4 purchasing covers the supplier evaluation for hosting providers, third-party libraries, SOUP components, and contracted engineering. Clause 7.5 production and service provision covers the release, deployment, and post-release service activities. Clause 7.6 on monitoring and measuring equipment is scoped narrowly or out entirely for software-only devices.

Clause 8 (measurement, analysis, and improvement) maps to the CAPA process, internal audits, post-market surveillance, vigilance reporting, and the data feedback loop. For a software startup, most clause 8 activity runs through the incident response and the PMS system — bug reports, customer feedback, usage telemetry, security events — with the records produced in the issue tracker and the incident management system.

The one thing the mapping does not do is remove any clause entirely. Every clause is either implemented, tailored, or justified as non-applicable with a written rationale. An auditor who sees a clause skipped without justification will not sign off.

## How EN 62304:2006+A1:2015 slots into clause 7.3

For software, EN ISO 13485:2016+A11:2021 clause 7.3 design and development is the outer frame, and EN 62304:2006+A1:2015 is the software lifecycle model that runs inside it. The adaptation move is to declare this mapping explicitly in the software development plan and in the QMS manual.

EN 62304:2006+A1:2015 clauses 5.1 through 5.8 cover development planning, requirements analysis, architectural design, detailed design, implementation and verification, integration and integration testing, system testing, and software release. These activities run in the agile cadence described in post 397, with clause 5.1 planning refreshed at sprint planning, clauses 5.2 to 5.6 distributed across sprints, clause 5.7 running as automated verification in CI, and clause 5.8 running at the release boundary. Clause 6 covers software maintenance after first release. Clause 7 covers software risk management, which sits inside the EN ISO 14971:2019+A11:2021 risk process at the QMS level. Clause 8 covers software configuration management and clause 9 covers software problem resolution.

For software of unknown provenance (SOUP) — third-party libraries and components whose development history cannot be fully audited — EN 62304:2006+A1:2015 clauses 5.3.3, 5.3.4, 7.1.3, 8.1.2 and related sub-clauses require specific handling: SOUP identification, version control, evaluation for anomalies, integration into the risk analysis, and monitoring for security advisories. The QMS procedure names the SOUP register, the evaluation workflow, and the monitoring cadence. For modern software teams, this is the dependency manifest plus a supply-chain security monitoring tool plus a documented triage process — not a new system.

Where the software is a standalone health software product, IEC 82304-1:2016 may be referenced as a general product-level safety and security standard. Where cybersecurity is a meaningful concern — and under MDR Annex I Section 17 it usually is — EN IEC 81001-5-1:2022 is the harmonised standard that provides presumption of conformity for cybersecurity activities across the product lifecycle. Both are tools the QMS can reference without duplicating EN 62304:2006+A1:2015.

## A worked agile scenario — how the QMS runs during one sprint

Consider a software-first MedTech startup of twelve engineers building a Class IIa MDSW that supports clinical decision-making in a hospital environment. The team runs two-week sprints. The QMS is a single ten-page manual plus a set of procedure documents in the repository, scoped to the product.

Sprint planning runs Monday morning. The product owner, tech lead, and two engineers refine three stories from the backlog. Each story is checked against the intended purpose statement and the current risk file. Two stories touch existing requirements; one story introduces a new requirement that goes into the requirements document in the repo via pull request. The risk lead flags one story that needs a new hazard analysis entry; the entry is drafted and linked to the story. Sprint planning minutes are captured as a comment on the sprint milestone in the ticket system. Clause 7.3.2 planning and clause 7.3.3 input activities have just run, with records produced where the work happens.

During the sprint, engineers pick stories, branch, write code, write tests, open pull requests. Each pull request links to its story, which links to the requirement and the risk entry. Peer review happens on the pull request with a documented approval. CI runs unit tests, integration tests, static analysis, and a build. CI logs are retained as verification evidence. Clause 7.3.4 output capture and clause 7.3.6 verification activities run continuously.

Mid-sprint, a customer reports a minor defect through the support channel. The incident is logged in the issue tracker, triaged against the risk file, evaluated for vigilance reporting under MDR Article 87, and — being a non-reportable minor defect — scheduled for the next maintenance sprint under EN 62304:2006+A1:2015 clause 6 and clause 9. The CAPA process under EN ISO 13485:2016+A11:2021 clause 8.5.2 is invoked for the trend, not for the single ticket. Records land in the tracker.

Sprint end. The sprint demo runs, the increment passes CI, and the team closes the sprint. No clause 7.3.5 design review runs — that review runs at the release boundary, not every sprint, as described in post 318. The increment is not a medical device release; it is an internal checkpoint.

Four sprints later, the release boundary is reached. The clause 7.3.5 formal design review runs, attended by engineering, quality, regulatory, and the risk lead, with minutes and a release recommendation. The clause 5.8 release activity under EN 62304:2006+A1:2015 runs, producing a signed release record linked to the verification evidence, the risk file state, and the version identifier. The new version is deployed to the production environment. PMS begins collecting post-market data against the release version. The QMS ran across four sprints and one release with no parallel bureaucracy and no retroactive reconstruction.

## The agile-compatible QMS playbook — what to build

The playbook for a software-first startup is shorter than founders expect.

One QMS manual, ten to twenty pages, scoping the standard to the product and naming the non-applicable clauses with rationale. One software development plan mapping the agile cadence to EN 62304:2006+A1:2015 clauses, as described in post 397. Procedures for the core processes: document control, record control, management review, training, supplier evaluation, design and development (pointing to the software development plan), purchasing (including SOUP), production and release, CAPA, internal audit, PMS, vigilance, and incident response. Each procedure is two to five pages and describes what the team actually does, not an aspirational process.

Records live where the work happens. Engineering records in the repository and the CI system. Management records in the ticket system and a minimal set of management review minutes. Regulatory records — DoC, technical documentation, risk management file, clinical evaluation, PMS plan — as structured artefacts in the repository.

Training records are a competence matrix plus evidence of training on the QMS itself, on EN 62304:2006+A1:2015, on EN ISO 14971:2019+A11:2021, and on the product-specific risk profile. New engineers complete an onboarding checklist that includes the QMS.

Supplier evaluation covers the hosting provider, the CI provider, critical third-party libraries, and any contracted engineering. The evaluation is proportional — a major hosting provider gets a review of their certifications and SLAs; a small open-source library gets a SOUP entry and monitoring. No one fills out a 40-page supplier questionnaire for AWS.

Management review runs quarterly with a real agenda — performance metrics, customer feedback trends, PMS data, CAPA status, audit findings, resource needs, strategic risks — and produces a minuted decision list.

Internal audit runs annually, scoped to the high-risk processes, conducted by someone independent of the process being audited (often an external consultant for a small startup). Findings are tracked to closure.

The whole system fits in one repository and one ticket system. The auditor walks in, asks for the QMS, and the team shows them the repository.

## Reality Check — Is your QMS actually built for how your team works?

1. Does your QMS manual explicitly scope EN ISO 13485:2016+A11:2021 to your software-first product, with each non-applicable clause named and justified in writing?
2. Does your software development plan map the agile cadence to EN 62304:2006+A1:2015 clauses, so the auditor can trace any activity from the standard to the sprint where it happens?
3. Are your QMS records stored where the engineering work happens — in the repository, in the CI system, in the ticket system — or in a parallel shared-drive binder no one opens?
4. Does your SOUP register list every third-party component with version, anomaly evaluation, and a monitoring source, and is it updated when dependencies change?
5. Does your management review happen on the stated cadence with real inputs and real outputs, or is it a ceremony reconstructed before each audit?
6. Is your CAPA process connected to the incident and trend data the engineering team already collects, or is it a separate spreadsheet with its own life?
7. When you hired your last engineer, did they go through QMS onboarding with a recorded outcome, or did they start coding before anyone mentioned the QMS?
8. Can you produce, for your most recent release, the exact QMS records associated with it — design review, verification, validation, risk file, release authorisation — without a week of reconstruction?
9. Does your scope statement name MDCG 2019-11 Rev.1 and justify the MDSW qualification and classification of your product?
10. If the auditor asked "show me how clause 7.3 runs here," would you point to the engineering workflow, or to a set of documents that describes a process the team no longer follows?

Any answer that is not a clear yes is a gap. Closing it is almost always a discipline and tooling fix, not a methodology change.

## Frequently Asked Questions

**Does a software-only MedTech startup really need a full EN ISO 13485:2016+A11:2021 QMS?**
Yes, for any device that falls under MDR. Article 10(9) requires a QMS proportionate to the risk class and type of device, and for most software medical devices the conformity assessment route under Annex IX depends on the notified body auditing that QMS against the harmonised standard. The proportionality allows non-applicable clauses to be scoped out with justification, but the backbone of the standard applies. A startup cannot opt out by being small or software-only.

**How do I map EN 62304:2006+A1:2015 into EN ISO 13485:2016+A11:2021?**
EN 62304:2006+A1:2015 is the software lifecycle model that runs inside clause 7.3 design and development of EN ISO 13485:2016+A11:2021. The QMS manual names the mapping explicitly. Clauses 5.1 to 5.8 of EN 62304:2006+A1:2015 cover the development lifecycle; clause 6 covers maintenance; clauses 7, 8, and 9 cover risk, configuration, and problem resolution. Each of these maps to a corresponding or adjacent clause in EN ISO 13485:2016+A11:2021, and the software development plan documents the mapping in one place.

**What about SOUP — do I need to document every npm package?**
Every SOUP component that is integrated into the released device has to be identified, versioned, evaluated for anomalies relative to the intended use, and monitored for security advisories. For a modern software team, this is the dependency manifest plus a supply-chain security tool plus a documented triage process — not a manual spreadsheet with every transitive dependency. The QMS procedure names the scope of what counts as a SOUP component for the device and how the register is maintained.

**Can I use git and my issue tracker as my QMS records system?**
Yes, provided they satisfy the document and record control requirements of EN ISO 13485:2016+A11:2021 clause 4.2. That means version history, change authorisation, retention, and retrievability. Git with pull request approvals satisfies most of these for engineering records. The issue tracker satisfies them for tickets and management records. The QMS procedure names the systems explicitly, documents the retention policy, and covers backup and recovery. Auditors have seen this configuration many times and will review it on its merits.

**How does MDCG 2019-11 Rev.1 affect my QMS scope?**
MDCG 2019-11 Rev.1 drives the qualification of the product as MDSW and the classification under Annex VIII Rule 11. The QMS scope statement has to name the MDSW product, state its intended purpose, cite the Rule 11 classification rationale, and reference MDCG 2019-11 Rev.1 as the guidance applied. This is not an extra document — it is a section of the QMS manual or the technical documentation that the auditor will read to understand what the QMS covers.

**How lean can the QMS actually be for a twelve-person software startup?**
Leaner than most founders expect. The manual is ten to twenty pages. Procedures are two to five pages each. Records live in the engineering tooling. One part-time quality role — often the CTO or a dedicated regulatory lead — runs the QMS alongside their other work. The whole system fits in one repository and one ticket system. What it cannot be is absent, unjustified, or reconstructed the week before the audit.

## Related reading

- [Agile Sprints and ISO 13485 Design Controls](/blog/agile-sprints-iso-13485-design-controls) — how clause 7.3 design controls reconcile with sprint cadence.
- [Agile Development Under MDR and IEC 62304](/blog/agile-development-mdr-iec-62304) — the software lifecycle reconciliation inside the clause 7.3 frame this post describes.
- [MDR Software Lifecycle Requirements](/blog/mdr-software-lifecycle-iec-62304) — the MDR Annex I Section 17 obligations that EN 62304:2006+A1:2015 operationalises.
- [MDR Design and Development Planning](/blog/mdr-design-development-planning) — the clause 7.3.2 planning activity that names the software development plan.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology pillar this post applies to the software-first QMS.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10(9), Annex IX, and Annex I Section 17. Official Journal L 117, 5.5.2017.
2. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Harmonised standard referenced for the QMS under MDR Article 10(9) and Annex IX.
3. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015). Harmonised standard referenced for the software lifecycle under MDR Annex I Section 17.2.
4. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices. Harmonised standard referenced for risk management under MDR Annex I.
5. IEC 82304-1:2016 — Health software — Part 1: General requirements for product safety. Product-level safety standard for standalone health software.
6. EN IEC 81001-5-1:2022 — Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle. Harmonised standard referenced for cybersecurity under MDR Annex I Section 17.
7. MDCG 2019-11 Rev.1 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR. June 2025.

---

*This post is a category-7 spoke in the Subtract to Ship: MDR blog, focused on adapting EN ISO 13485:2016+A11:2021 to software-first MedTech startups running agile development. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — EN ISO 13485:2016+A11:2021, EN 62304:2006+A1:2015, EN ISO 14971:2019+A11:2021, IEC 82304-1:2016, and EN IEC 81001-5-1:2022 are harmonised or referenced tools that provide presumption of conformity with specific MDR obligations, not independent authorities. For startup-specific regulatory support on building a lean, auditable QMS for software-first teams, Zechmeister Strategic Solutions is where this work is done in practice.*

---

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