--- title: MDR Software Documentation Package: IEC 62304 Checklist description: The complete IEC 62304 software documentation package for MDR conformity: every artefact, every clause, and what each document must contain. authors: Tibor Zechmeister, Felix Lenhard category: Software as a Medical Device primary_keyword: software documentation package IEC 62304 MDR canonical_url: https://zechmeister-solutions.com/en/blog/software-documentation-package-iec-62304 source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # MDR Software Documentation Package: IEC 62304 Checklist *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **An IEC 62304 software documentation package for MDR is not a single file. It is roughly a dozen controlled artefacts — plan, requirements, architecture, detailed design, unit and integration and system test records, release documentation, problem resolution, configuration management, maintenance plan — each mapped to a specific clause of EN 62304:2006+A1:2015 and referenced from Annex II §6.1 of the technical documentation.** **By Tibor Zechmeister and Felix Lenhard.** ## TL;DR - MDR Annex II §6.1 requires that the technical documentation contain a full description of the software design, development and verification for any device incorporating software. - EN 62304:2006+A1:2015 is the presumption-of-conformity standard for software lifecycle processes and defines the artefacts a notified body will expect to see. - The artefact set scales with the software safety class (A, B, C) defined in clause 4.3, but the structure of the package does not. - A lean team can ship a full package with roughly eleven core documents if templates are wired to risk management (EN ISO 14971:2019+A11:2021) and the QMS from day one. - Missing traceability between requirements, architecture, tests and risk controls is the single most common software non-conformity in notified body audits. ## Why this matters When a notified body auditor opens your software folder, they are not reading your code. They are reconciling three things: what you said the software should do, what you built, and what you tested — and they are doing it against a specific clause list inside EN 62304. Founders often arrive at the audit with a pile of Confluence pages, a Jira export, and a conviction that "it is all in the repo." It is not. The repo is evidence. The documentation package is the argument. Without the argument, the evidence has no structure, and the auditor cannot confirm conformity with MDR Annex I §17 (the GSPR clause on electronic programmable systems and software) or Annex II §6.1 (the technical documentation contents). The good news: the artefact list is finite. It has been the same for twenty years. Once you have the structure, you can keep it lean, you can automate large parts of it, and you can reuse it across versions. ## What MDR and EN 62304 actually require MDR Annex I §17.2 requires that software be developed and manufactured in accordance with the state of the art, taking into account the principles of development lifecycle, risk management, verification and validation. The harmonised path to demonstrating conformity with §17.2 is EN 62304:2006+A1:2015. MDR Annex II §6.1 then demands, inside the technical documentation, a description of the pre-clinical and clinical data — and explicitly calls out software verification and validation. Read together, Annex I tells you what good looks like, Annex II tells you what must be in the file, and EN 62304 tells you the shape of the artefacts. EN 62304 organises the lifecycle into software development process (clause 5), software maintenance process (clause 6), software risk management process (clause 7), software configuration management process (clause 8), and software problem resolution process (clause 9). Each process generates specific documented outputs. Those outputs are the package. The safety class drives which sub-activities apply. Class A (no injury possible), Class B (non-serious injury possible), Class C (serious injury or death possible). Clause 4.3 defines the rules. The package structure is identical; the depth varies. ## The complete artefact checklist Here is the master checklist. Treat it as a table of contents for your software section of the technical file. **1. Software development plan (clause 5.1).** The controlling document. References the lifecycle model, the safety class justification, the deliverables, the responsibilities, the tools, the standards applied, the integration strategy, the verification strategy, the configuration management approach, the problem resolution approach, and the links to risk management. Without a plan, clause 5.1 is an automatic finding. **2. Software requirements specification, SRS (clause 5.2).** Functional, capability, interface, environment, data, regulatory and risk control requirements. Every requirement must be uniquely identified, verifiable, and traceable forward to architecture and tests and backward to system requirements and risk controls. We cover this in detail in the companion post on the SRS. **3. Software architecture document (clause 5.3).** Decomposes the software into items and, for Class B and C, identifies which items implement risk controls. Includes interfaces between items, interfaces to external components, SOUP identification, and segregation arguments for safety-related items. Separate post covers the architecture doc in depth. **4. Software detailed design (clause 5.4).** Required for Class C software units. Describes each unit to a level that supports coding and unit verification. For Class B, detailed design is at the software item level, not the unit level. For Class A, clause 5.4 does not apply. **5. Unit implementation and verification records (clauses 5.5 and 5.6).** Coding standards applied, static analysis output where used, unit test plans and results for Class B and C units that implement risk controls. Evidence, not just claims. **6. Software integration and integration testing records (clause 5.6).** Integration plan, integration test cases, actual test results, regression coverage, and evidence that integration anomalies were handled through the problem resolution process. **7. Software system test records (clause 5.7).** System-level test plan and results demonstrating that the software fulfils the software requirements specification. Traceability from every SRS item to at least one system test case is the auditor's first look. **8. Software release documentation (clause 5.8).** Release criteria, known anomalies list with risk assessment rationale for each anomaly not fixed, the released versions of all SOUP, the build environment record, and the archived release baseline. This is the artefact that closes the development process. **9. Software maintenance plan (clause 6.1).** Defines how feedback, problems and change requests are received, evaluated, and implemented post-release. For startups, this is usually a short document that delegates to PMS and CAPA procedures from the QMS. **10. Software problem resolution records (clause 9).** Problem reports, investigations, root cause analyses, change evaluations, verification of fixes, and trending. Tooling (issue trackers) is acceptable evidence, but the process description and sample records belong in the file. **11. Software configuration management plan and records (clause 8).** Configuration items list including all SOUP with version, the change control procedure, the build and baseline management approach, and the configuration status accounting records. **12. Software risk management file contribution (clause 7 and EN ISO 14971:2019+A11:2021).** Software hazards, contributing causes, risk controls implemented in software, verification of risk controls, and residual risk evaluation. This is not a separate document — it is the software slice of the device-level risk management file, traceable to the SRS and architecture. That is the package. Eleven documents plus the risk management contribution. For Class A you drop detailed design and most of clause 5.5 to 5.7 content. For Class C you add detailed design at unit level and stricter verification. ## A worked example A two-founder startup building a Class IIa Rule 11 diagnostic support app, software safety Class B, targeting first CE mark in twelve months. They used a single Git repository with a `/quality` folder for documentation, all markdown, all version-controlled. Eleven documents, between three and twenty-five pages each. The SRS had 142 requirements. The architecture doc had five software items and two SOUP (a charting library and a PDF renderer). The system test suite had 98 test cases, run automatically on every release candidate, results archived. Their notified body audit took 1.5 days for the software section. The auditor asked for three things: (1) show me the release baseline for the version being assessed, (2) walk me from SRS-047 (an alerting requirement that implemented a risk control) through architecture, unit, integration and system test, (3) show me the anomaly list and justify the three open items. The team answered all three in under an hour because the traceability matrix was generated from the markdown files. Zero findings on the software section. The entire software documentation package was about 160 pages when exported to PDF. Not small, but not crushing — and every page had a clause number in the footer linking it back to EN 62304. ## The Subtract to Ship playbook **Start with the plan, not the code.** Write the software development plan first. It will be wrong in week two, but having a wrong plan is better than having no plan, because it forces explicit decisions about lifecycle, safety class and tooling. **Classify once, honestly.** The software safety class decision (clause 4.3) drives everything downstream. Over-classifying creates crushing documentation load; under-classifying creates audit risk. Get it right once and document the reasoning. **Write requirements before architecture.** It sounds obvious. It is rarely done. Teams draw architecture diagrams while requirements are still verbal. The result is architecture that cannot be traced to requirements, which is exactly what clause 5.3.6 and auditors check. **Use one traceability spine.** One identifier scheme for system requirements, software requirements, architecture items, test cases and risk controls. Machine-readable. Regenerate the matrix on every commit. If your matrix is a manual Excel file, you will fall behind within a sprint. **Treat SOUP as configuration items from day one.** Every third-party library, every cloud service, every runtime. Name, version, supplier, known anomalies check, justification for use. Add to the list when you add the dependency, not the week before the audit. **Wire the problem resolution process to your issue tracker.** Clause 9 does not mean you need a separate bug database. It means your existing tracker needs the right fields: problem description, investigation, classification, change evaluation, verification. Add three custom fields and you are compliant. **Freeze release baselines.** Every CE-marked release must have an archived snapshot: source code tag, built binaries or container images, SOUP versions, test results, and the signed release documentation. If you cannot rebuild a version one year after release, clause 5.8 is not satisfied. For the wider context on how this package lives inside the device-level technical file, see our piece on [how software documentation fits the technical file](/blog/software-documentation-technical-file). For the lifecycle framing of EN 62304 itself, start with [the MDR software lifecycle under IEC 62304](/blog/mdr-software-lifecycle-iec-62304). Before touching the package, confirm your [software safety classification under IEC 62304](/blog/software-safety-classification-iec-62304). ## Reality Check 1. Can you produce the current software development plan in under sixty seconds, and does it match what your team is actually doing this sprint? 2. Does every requirement in your SRS have a unique ID that appears in at least one test result? 3. Is your SOUP list current to this week, with versions and known anomaly checks? 4. If the auditor picks one risk control from your risk management file, can you walk it to the code, the test and the release baseline? 5. Do you have an archived, rebuildable baseline for every CE-marked version? 6. Has anyone outside the engineering team read your software development plan? 7. Is your problem resolution evidence in the same system your developers actually use? 8. When was the last time the traceability matrix was regenerated — this week, or last quarter? If you answered "no" or "not sure" to three or more, the package exists on paper but not in practice. ## Frequently Asked Questions **Do I need all eleven documents for Class A software?** You need the plan, SRS, architecture, release documentation, configuration management, problem resolution, maintenance plan, and the risk management contribution. Detailed design is not required. Unit and integration testing records are reduced. You still need system testing against the SRS. **Can I combine the plan, SRS and architecture into one document?** Technically yes — EN 62304 does not mandate separate files. Practically no. Auditors expect the clause structure to be navigable, and combining documents makes change control harder. **Is a wiki acceptable as documentation?** A controlled wiki with version history, access control and approval workflows can satisfy EN ISO 13485:2016+A11:2021 document control. Uncontrolled wikis (anyone can edit, no history) cannot. **How long should each document be?** As long as it needs to be and no longer. A Class B SRS under 30 pages is suspicious. Over 150 pages suggests the author did not distinguish requirements from design. **Do I need to document agile sprints as lifecycle phases?** No. EN 62304 is lifecycle-model agnostic. Your plan declares how you map your actual process (iterative, incremental, agile) to the clauses. See our post on agile development under EN 62304. **What if my SOUP has unresolved anomalies?** Clause 5.3.3 requires you to evaluate anomalies in SOUP that could contribute to a hazardous situation. Document the evaluation, not the absence of anomalies. "No relevant anomalies" is a valid conclusion if justified. ## Related reading - [Software documentation in the technical file](/blog/software-documentation-technical-file) — how the software package sits inside Annex II. - [MDR software lifecycle under IEC 62304](/blog/mdr-software-lifecycle-iec-62304) — the process view behind the artefacts. - [Software safety classification](/blog/software-safety-classification-iec-62304) — the Class A/B/C decision that scales the package. - [Software requirements under IEC 62304](/blog/software-requirements-iec-62304) — the SRS companion post. - [Software architecture documentation under IEC 62304](/blog/software-architecture-documentation-iec-62304) — clause 5.3 in depth. ## Sources 1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §17, Annex II §6.1. 2. EN 62304:2006+A1:2015 — Medical device software — Software life cycle processes. Clauses 4 through 9. 3. EN ISO 14971:2019+A11:2021 — Application of risk management to medical devices. 4. EN ISO 13485:2016+A11:2021 — Quality management systems for medical devices. --- *This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) 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).*