Software Documentation in the Technical File: What MDR and IEC 62304 Require

Software documentation in the technical file under MDR is the set of artefacts produced by the EN 62304:2006+A1:2015 software lifecycle, the EN IEC 81001-5-1:2022 cybersecurity lifecycle, and the EN ISO 14971:2019+A11:2021 risk-management process, filed under Annex II of Regulation (EU) 2017/745 and traced to the applicable General Safety and Performance Requirements in Annex I Section 17. The complete document set is the software development plan, software requirements specification, software architecture, software detailed design (for Class B and C items), software verification and system testing records, software configuration management record, software problem resolution record, software release record, software maintenance plan, SOUP list with evaluation and monitoring, software risk management outputs integrated into the risk file, and the cybersecurity lifecycle artefacts under EN IEC 81001-5-1:2022. Every artefact has a home inside Annex II. None of them are optional.

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

TL;DR

• MDR Annex I Section 17 is the binding requirement for software. Annex II is where the evidence has to live. The two annexes read together define the software documentation obligation.
• EN 62304:2006+A1:2015 produces the core lifecycle artefacts that populate the software sections of Annex II.
• EN IEC 81001-5-1:2022 produces the cybersecurity-lifecycle artefacts that sit alongside them and are referenced by MDCG 2019-16 Rev.1.
• SOUP (software of unknown provenance) documentation is a specific EN 62304:2006+A1:2015 obligation: identify, evaluate, monitor, and control every third-party software item.
• The most common gap at audit is not missing content. It is software documentation that exists as a standalone binder disconnected from the Annex II structure, with broken traceability into the GSPR checklist and the risk file.

Why the software documentation question is its own problem

A competent engineering team can produce every artefact EN 62304:2006+A1:2015 asks for and still fail the technical file review. The failure mode is not the quality of the software work. It is the placement. The software development plan lives in a Confluence space. The requirements live in Jira. The architecture lives in a repo README. The SOUP list lives in a spreadsheet on one engineer's laptop. The cybersecurity risk assessment lives in a vendor report. None of it is wrong. None of it is where Annex II expects to find it, and the GSPR checklist cannot resolve its cross-references because the references point to tools that the Notified Body auditor cannot open. The software documentation exists. The technical file does not contain it.

This is the gap this post addresses. EN 62304:2006+A1:2015 tells you what activities to run and what outputs those activities produce. Annex II of Regulation (EU) 2017/745 tells you where those outputs have to live inside the technical file and how they connect to the rest of the conformity argument. Both are required. Neither is sufficient alone.

What Annex II requires for software

Annex II of Regulation (EU) 2017/745 is the section-by-section specification of the technical documentation. It does not contain a standalone "software" chapter. Software documentation is woven through the annex in the places where software evidence is required to demonstrate conformity with Annex I.

Section 1 of Annex II — device description and specification — requires a description of the principles of operation of the device. For software-containing devices that description includes the software functions, the software safety classification under EN 62304:2006+A1:2015 at the software-item level, and the intended operating environment. For standalone MDSW, Section 1 also covers the software release version and the classification rationale under Annex VIII Rule 11.

Section 3 — design and manufacturing information — requires a description of the design stages applied to the device. For software, that is the lifecycle model declared in the software development plan, the list of suppliers involved in the software supply chain, and the controls applied to them.

Section 4 — the GSPR checklist — is where Annex I Section 17 is answered. Every applicable sub-requirement of Section 17 is listed with the method of conformity demonstration and a reference to the specific evidence in the file. The referenced evidence is the EN 62304:2006+A1:2015 output set and the EN IEC 81001-5-1:2022 cybersecurity outputs.

Section 5 — benefit-risk and risk management — pulls in the EN ISO 14971:2019+A11:2021 risk management file, which integrates the software-specific risk analysis required under EN 62304:2006+A1:2015.

Section 6 — product verification and validation — is where the bulk of the raw software evidence lives. The software verification reports, integration testing, system testing, release record, and associated test logs are filed here with version control.

The technical documentation pillar post walks through Annex II as a whole. This post narrows the lens to the software-specific artefacts that land inside it.

The EN 62304 document set

EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes — is the harmonised standard referenced for the software lifecycle under MDR Annex I Section 17.2. It produces a specific set of documented outputs. Every output has to find a home in the technical file.

• Software development plan. Scope of the software, lifecycle model, deliverables, responsibilities, verification activities, integration of risk management, configuration management approach, problem resolution approach, maintenance strategy. The software development planning post covers the plan in detail.
• Software requirements specification. Functional, interface, performance, safety, security, and environmental requirements, each traceable upward to the system requirements and downward to the design and verification activities. The software requirements analysis post goes deeper.
• Software architecture description. The top-level software items and the interfaces between them, with the segregation arguments that support the software safety classification. Covered in the architecture and detailed design post.
• Software detailed design. Required for Class B at the software-item level and Class C at the unit level. Not required for Class A software.
• Software unit implementation and verification records. Coding standards, unit test evidence, code review records, static analysis output. Scale depends on the software safety class.
• Software integration and integration testing records. Required for Class B and Class C. The verification and system testing post covers this and the system testing records.
• Software system testing records. Evidence that the software meets the requirements specification. Required for all classes.
• Software release record. The documented decision to release a specific verified version of the software, with evidence that planned activities are complete and anomalies evaluated.
• Software configuration management record. The reproducible lineage of every release — source, third-party dependencies, build scripts, tools. See the configuration management post.
• Software problem resolution record. The anomaly log, the investigation and disposition, the link to risk management and to affected versions. See the problem resolution post.
• Software maintenance plan. The planned approach for handling bug fixes, feature additions, and security patches post-release, under the same lifecycle discipline.

Mapping standard outputs to Annex II sections

This is the step most teams skip and pay for later. Every EN 62304:2006+A1:2015 output has a specific home in Annex II. The mapping is not ambiguous and it is not optional.

The GSPR checklist in Section 4 does not store the evidence. It points to the evidence in Sections 1, 3, 5, and 6, and the references have to resolve to the exact document and version listed.

Cybersecurity documentation per EN IEC 81001-5-1:2022

MDR Annex I Section 17.2 explicitly names information security as part of the software lifecycle obligation. 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 — is the harmonised standard that operationalises the cybersecurity lifecycle. It sits alongside EN 62304:2006+A1:2015, not instead of it.

The cybersecurity artefacts the standard produces and that a Notified Body will expect to find in the technical file are these. A security risk assessment that integrates with the EN ISO 14971:2019+A11:2021 risk management file and identifies threats, vulnerabilities, and the corresponding controls. A security requirements specification derived from the risk assessment. A secure-by-design architecture description. Verification evidence for the security controls — penetration testing, vulnerability scanning, fuzzing where applicable. A software bill of materials (SBOM) listing every third-party component with version and known-vulnerability status. A vulnerability monitoring and disclosure process that continues after release. A secure release and update mechanism with integrity verification.

MDCG 2019-16 Rev.1 (July 2020) is the guidance document that maps the MDR/IVDR Annex I cybersecurity requirements onto concrete lifecycle activities and that Notified Bodies use as their interpretation reference. The cybersecurity documentation spoke post walks through the full artefact set and how it integrates with Annex II.

The cybersecurity lifecycle evidence lives in Annex II Section 6 alongside the EN 62304:2006+A1:2015 verification evidence, with the security risk outputs feeding the Section 5 risk management file and the security-related GSPR items answered in Section 4. One file, two parallel lifecycles, fully integrated traceability.

SOUP documentation

SOUP — software of unknown provenance — is the EN 62304:2006+A1:2015 term for third-party software that the manufacturer did not develop under the standard but that is incorporated into the medical device software. Operating systems, libraries, runtime frameworks, open-source components, vendor SDKs, and commercial middleware all qualify. Most modern medical software contains hundreds of SOUP items.

EN 62304:2006+A1:2015 requires the manufacturer to document specific information about every SOUP item. The identifier and version. The functional and performance requirements the SOUP is required to meet. The hardware and software environment the SOUP runs in. The known anomalies of the SOUP version in use and an evaluation of whether any of those anomalies contribute to a hazardous situation. The rationale for selecting the specific SOUP version, where the selection is safety-relevant.

The SOUP list is a controlled document. It is updated every time a dependency is added, removed, or upgraded. It integrates with the cybersecurity SBOM — the SBOM is the machine-readable generation of the same underlying list, extended with vulnerability metadata. Under EN IEC 81001-5-1:2022 the SBOM is a specific deliverable; under EN 62304:2006+A1:2015 the SOUP list is the functional and safety view of the same dependency set. A competent team maintains both from a single source and keeps them synchronised automatically.

At audit, the SOUP list is sampled the same way the GSPR checklist is sampled. The auditor picks a SOUP item and asks to see the evaluation, the version history, the anomaly review, and the monitoring record. If any of those are missing or stale, it is a finding.

Common gaps

The patterns that surface across software technical file audits are consistent enough to name.

• Software documentation in the wrong tools. Requirements in Jira, architecture in a wiki, test results in CI only. None of it under document control per EN ISO 13485:2016+A11:2021. The auditor cannot reach it and the GSPR checklist cannot resolve references to it.
• Software development plan missing or generic. A template that was never customised for the actual team. The plan describes a process the team does not run.
• Software safety classification assigned at device level, not item level. Bulk Class C on everything "to be safe," or bulk Class A without hazard analysis. Neither position survives a trained reviewer.
• SOUP list missing, stale, or not under version control. The single fastest audit finding in software-containing devices.
• Cybersecurity treated as a one-time assessment. A penetration test report from 18 months ago with no ongoing vulnerability monitoring, no SBOM, no disclosure process.
• Risk file separated from software. An EN ISO 14971:2019+A11:2021 file that does not integrate the EN 62304:2006+A1:2015 software risk outputs or the EN IEC 81001-5-1:2022 security risk outputs.
• Release record absent. The team ships continuously but cannot produce a documented release decision for the version on the market.
• Maintenance plan missing. No planned approach for handling post-release changes under the lifecycle. Changes happen; evidence that they went through the lifecycle does not.
• Traceability breaks between Annex II sections. The GSPR checklist points to documents that no longer exist under the name cited, or to versions that have been superseded without the reference being updated.

Each of these is a findability or traceability failure, not an engineering failure. The engineering work is usually present. The discipline of filing it where Annex II expects it is what is missing.

The Subtract to Ship angle

Software documentation is the category where the urge to add is strongest. Every standard has a template library. Every consultant has a binder structure. Every QMS tool ships with pre-built document types. The path of least resistance is to accept all of them and produce a parallel documentation stack that duplicates what the engineering team already does.

The Subtract to Ship discipline for software documentation is the opposite move. Every artefact in the technical file has to trace to a specific clause of EN 62304:2006+A1:2015, EN IEC 81001-5-1:2022, EN ISO 14971:2019+A11:2021, or Annex II of Regulation (EU) 2017/745. Artefacts that do not trace come out. The engineering team's existing requirements, architecture, configuration management, and CI evidence become the source of truth — the technical file references them and filters them into Annex II shape rather than replacing them with parallel documents. The Subtract to Ship framework for MDR compliance applies here exactly as it applies to the rest of the file: subtract until what remains earns its place against a specific obligation. The software compliance checklist for startups is the operational checklist that the subtraction runs against.

Reality Check — Where do you stand?

1. For every EN 62304:2006+A1:2015 output listed in this post, can you name the document, the version, the owner, and the Annex II section it lives under?
2. Does your GSPR checklist in Annex II Section 4 answer every applicable sub-requirement of Annex I Section 17 with a resolvable reference to software evidence?
3. Is your software safety classification assigned at the software-item level, with the reasoning linked to the EN ISO 14971:2019+A11:2021 risk file?
4. Is your SOUP list under document control, current with the code base, and integrated with a machine-readable SBOM?
5. Do you have a security risk assessment, security requirements, verification evidence, SBOM, and vulnerability monitoring process under EN IEC 81001-5-1:2022, filed inside Annex II?
6. Can you produce a documented software release record for the version of the software currently on the market?
7. Is your maintenance plan written and running, or is post-release change management improvised?
8. Does your EN ISO 14971:2019+A11:2021 risk file integrate the software and security risk outputs, or do they sit in parallel silos?
9. Do the references in your GSPR checklist resolve today to the exact document and version cited?
10. If the Notified Body opened your technical file tomorrow, would the software documentation be findable inside Annex II, or would it be scattered across tools the auditor cannot access?

Frequently Asked Questions

Does software documentation go in Annex II or Annex III under MDR? Both, in different roles. The main software lifecycle documentation — development plan, requirements, architecture, verification, release — lives in Annex II, primarily in Sections 1, 3, 5, and 6, with the GSPR checklist in Section 4 tying it back to Annex I Section 17. The post-market side of the software lifecycle — problem resolution records arising from field use, maintenance activities, security updates, vulnerability monitoring — feeds into Annex III post-market surveillance documentation as it accumulates. The two files are linked and update each other.

Is the EN 62304 software development plan the same document as the QMS design and development procedure? No, but they have to be consistent. The QMS procedure under EN ISO 13485:2016+A11:2021 is the organisation-level process description. The EN 62304:2006+A1:2015 software development plan is the product-level plan that applies the QMS procedure to a specific software product. One is generic; the other is specific. Both exist. Both are under document control.

Do I need a separate cybersecurity technical file? No. The cybersecurity documentation lives inside the Annex II technical file alongside the EN 62304:2006+A1:2015 lifecycle evidence. EN IEC 81001-5-1:2022 provides the lifecycle activities, MDCG 2019-16 Rev.1 provides the interpretation, and Annex II provides the home. A parallel cybersecurity binder is a common startup mistake and an audit findability problem.

What is the minimum SOUP documentation EN 62304 requires? For each SOUP item: identifier and version, functional and performance requirements the SOUP must meet, hardware and software environment, known anomalies in the version used and a hazard-relevance evaluation of those anomalies, and the rationale for selecting the version. The list is a living document. For cybersecurity, the SBOM extends the same list with vulnerability metadata under EN IEC 81001-5-1:2022.

How detailed does the software architecture description need to be for a Class A software item? EN 62304:2006+A1:2015 requires architectural design for all software, but the depth scales with class. For Class A, the architecture can be a high-level description of the software items and their interfaces, sufficient to support the safety classification argument. Class A does not require detailed design. Class B requires detailed design at the software-item level. Class C requires detailed design down to the unit level.

Can automated CI evidence serve as the verification records in the technical file? Yes, and it is the right approach. The standard requires documented evidence, not hand-written test reports. Automated CI logs with version stamps, commit hashes, and pass/fail records are acceptable verification evidence provided they are captured, retained under document control, and linked from the technical file. The regulatory artefact is the retained run log. The verification and system testing spoke post covers the approach in detail.

Related reading

• Technical Documentation Under MDR — the Annex II pillar this post sits under.
• MDR Annex II Structure, Section by Section — the section walkthrough for the whole file.
• What Is Software as a Medical Device (SaMD)? The MDR Definition for Startups — the qualification step that scopes what this documentation covers.
• MDCG 2019-11: Guidance on Qualification and Classification of Software — the EU guidance on whether your software is in scope.
• MDR Software Lifecycle Requirements: How IEC 62304 Helps You Demonstrate Conformity — the EN 62304:2006+A1:2015 lifecycle in full.
• Software Development Planning Under EN 62304 — the plan artefact in detail.
• Software Requirements Analysis Under EN 62304 — the requirements artefact in detail.
• Software Architecture and Detailed Design Under EN 62304 — the design artefacts in detail.
• Software Verification and System Testing Under EN 62304 — the verification artefacts in detail.
• Software Configuration Management Under EN 62304 — the configuration management record in detail.
• Software Problem Resolution Under EN 62304 — the problem resolution record in detail.
• MDR Software Compliance Checklist for Startups — the operational checklist the subtraction runs against.
• The Subtract to Ship Framework for MDR Compliance — the methodology this post applies to software documentation.

Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex I Section 17 (electronic programmable systems and software), Annex II (technical documentation). Official Journal L 117, 5.5.2017.
2. 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.
3. 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 (IEC 81001-5-1:2021). Harmonised standard referenced for the cybersecurity lifecycle under MDR Annex I Section 17.
4. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.
5. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes.
6. MDCG 2019-16 Rev.1 — Guidance on Cybersecurity for medical devices. December 2019; Revision 1, July 2020.

This post is a Category 5 spoke in the Subtract to Ship: MDR blog, sitting under the Technical Documentation pillar and intersecting the Software as a Medical Device cluster. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — EN 62304:2006+A1:2015 and EN IEC 81001-5-1:2022 are the harmonised tools that provide presumption of conformity with specific parts of Annex I Section 17, not independent authorities. For startup-specific support on software documentation, SOUP management, and cybersecurity lifecycle implementation, Zechmeister Strategic Solutions is where this work is done in practice.