--- title: Technical Documentation for Software as a Medical Device: Special Considerations description: SaMD technical documentation has special considerations under MDR Annex II. Here is what differs from physical-device tech files. authors: Tibor Zechmeister, Felix Lenhard category: Technical Documentation & Labeling primary_keyword: technical documentation SaMD special considerations canonical_url: https://zechmeister-solutions.com/en/blog/technical-documentation-samd-special source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # Technical Documentation for Software as a Medical Device: Special Considerations *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **Software as a Medical Device (SaMD) has to be filed under the same Annex II of Regulation (EU) 2017/745 as every other medical device, but the content that fills each section looks different. There is no physical device to describe, so the device description section becomes a description of software functions, intended operating environment, and release versions. The labels are rendered by the software itself rather than printed on a box. The cybersecurity lifecycle is not an overlay — it is load-bearing evidence for Annex I Section 17. And version control becomes a regulatory question because every build the users interact with has to map back to a specific technical file state. MDCG 2019-11 Rev.1 (June 2025) is the EU interpretation layer that scopes what SaMD is and how the documentation has to track. The rules do not change for SaMD. The shape of the evidence does.** **By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.** --- ## TL;DR - SaMD technical documentation sits under MDR Annex II like any other device, but each section is populated with software-shaped evidence rather than physical-device artefacts. - Annex I Section 17 is the binding requirement for software and security; EN 62304:2006+A1:2015 is the harmonised lifecycle tool that produces most of the evidence. - MDCG 2019-11 Rev.1 (June 2025) is the EU guidance document that defines when software qualifies as a medical device and how it is classified under Annex VIII Rule 11. - The four special considerations are the device description shape, labelling rendered in the user interface, the cybersecurity overlay on top of the software lifecycle, and the version-control question linking each released build to a technical file state. - The most expensive SaMD failure mode is a technical file that describes "the product" at a marketing level while the software ships new versions every sprint that the file never catches up to. --- ## What is unique about SaMD technical documentation A physical device has a box, a label printed on the box, a serial number engraved on the casing, a paper IFU in the packaging, and a production line that turns out a stable article to a fixed design. Software as a Medical Device has none of that. It has a build pipeline, a release channel, a version number, a user interface that renders the labelling at runtime, and a deployment model where the article the user holds today is not the article the user held three weeks ago. Annex II of Regulation (EU) 2017/745 was written to be device-agnostic, and it is. But the evidence you slot into each section looks different, and the failure modes are different, and the auditor questions are different. MDCG 2019-11 Rev.1 (June 2025) is the guidance document the EU published to scope what counts as SaMD in the first place — "Medical Device Software" in the EU's own terminology — and how classification works under Annex VIII Rule 11. If your software meets the MDCG 2019-11 Rev.1 qualification criteria, it is a medical device, and the full weight of Annex II applies. The [what is SaMD under MDR post](/blog/what-is-software-as-medical-device-samd-mdr) walks through the qualification question. The rest of this post assumes the qualification answer is yes and focuses on what the technical documentation has to look like. The principle is simple and worth saying up front. SaMD does not have a reduced technical file. It has a differently-shaped technical file. Every Annex II section still applies. Every GSPR that applies to the intended purpose still has to be answered. The work of producing the file is not smaller. The shape of the work is different. ## Mapping EN 62304 outputs to Annex II for a software-only device The [software documentation in the technical file post](/blog/software-documentation-technical-file) lays out the general mapping of EN 62304:2006+A1:2015 outputs to Annex II sections for any software-containing device. For SaMD specifically, the mapping tightens because the software-lifecycle evidence is not part of the file — it is the file. A physical-device tech file has EN 62304:2006+A1:2015 evidence sitting alongside biocompatibility, electrical safety, sterilisation, and mechanical testing. A SaMD tech file has EN 62304:2006+A1:2015 evidence sitting alongside, essentially, more EN 62304:2006+A1:2015 evidence, cybersecurity lifecycle evidence, clinical evaluation, and usability. Annex II Section 1 — device description and specification — for a SaMD covers the software functions, the intended operating environment (supported operating systems, browser versions, hardware requirements, network assumptions), the software safety classification at the software-item level under EN 62304:2006+A1:2015, the classification rationale under Annex VIII Rule 11 with MDCG 2019-11 Rev.1 as the interpretation reference, the intended users and patient population, and critically the software release version the file currently describes. This is where the shape starts to diverge from a physical-device file. The release version is not cosmetic — it defines which artefact the rest of the file is about. Annex II Section 3 — design and manufacturing information — for SaMD becomes the description of the software development process, the lifecycle model from the EN 62304:2006+A1:2015 software development plan, the build and release pipeline, the configuration management approach, and the list of suppliers in the software supply chain (SOUP vendors, cloud infrastructure, third-party SDKs). "Manufacturing" for SaMD is the act of producing a release — the controlled build of a specific version from a specific source-code state with a specific set of dependencies. Annex II Section 4 — the GSPR checklist — for SaMD answers Annex I Section 17 in depth and Annex I Section 14.2(d) (the "software shall be designed and manufactured in accordance with the state of the art" obligation for devices incorporating software) where applicable. The general Annex I items around information supplied with the device, usability, and benefit-risk still apply. Items that do not apply to a software-only product (sterility, biocompatibility, electrical mains safety) are marked non-applicable with reasoning. The Annex II discipline of "never silent gaps" applies unchanged. Annex II Section 5 pulls in the EN ISO 14971:2019+A11:2021 risk management file with the software-specific risk analysis from EN 62304:2006+A1:2015 and the security risk outputs from the cybersecurity lifecycle. Section 6 holds the verification and validation evidence — the software V&V records, the usability engineering file, and the clinical evaluation report. The usability evidence matters more for SaMD than most founders expect because the user interface is where the device meets the user, and a usability failure in the UI is a device failure. ## The labelling-in-software section Annex II Section 2 covers the information supplied by the manufacturer — labels and instructions for use. For a physical device this is the box label, the device label, the IFU leaflet. For SaMD there is no box. The labelling is rendered by the software itself. The regulatory concept does not change. The obligation is that the user receives the information the Regulation requires, in the languages the Regulation requires, before and during use of the device. The implementation is that the information appears inside the software — on the splash screen, in the "about" dialog, in a dedicated IFU section of the UI, on the first-run onboarding, or in an accessible help menu. The electronic IFU regulation (Commission Implementing Regulation (EU) 2021/2226, consolidated with (EU) 2025/1234) governs electronic IFU provision and sets conditions on availability, language, and version management. Annex II Section 2 for a SaMD contains the rendered labelling content under document control. Not a screenshot taken at some point in the past. A controlled source for the label and IFU text, with the version the file describes, and a clear link to the release build that renders it. The label text and the IFU text are themselves document-controlled artefacts per EN ISO 13485:2016+A11:2021, and the mapping between the text in the file and the text rendered at runtime has to survive an auditor asking "show me where this sentence lives in the source code and how you verify it appears in the UI." The [labelling a Software as a Medical Device post](/blog/labeling-software-medical-device) goes deeper into the rendered-label mechanics. For this post the point is that Section 2 still exists, it still needs content, and the content is shaped by the fact that the label is rendered in a UI at runtime and has to stay synchronised with what the technical file says it is. ## The cybersecurity overlay For a physical electromechanical device with a USB port, cybersecurity is an overlay on top of a mostly physical conformity argument. For SaMD, cybersecurity is not an overlay. It is load-bearing evidence for Annex I Section 17. Annex I Section 17.2 requires information security measures appropriate to the risks, and Annex I Section 17.4 requires minimum IT requirements to be communicated to the user. EN IEC 81001-5-1:2022 is the harmonised standard referenced for the cybersecurity lifecycle, and MDCG 2019-16 Rev.1 (July 2020) is the interpretation layer Notified Bodies use. For a SaMD the cybersecurity lifecycle runs in parallel with the EN 62304:2006+A1:2015 software lifecycle and produces artefacts that sit directly inside Annex II. Security risk assessment integrated with the EN ISO 14971:2019+A11:2021 risk file. Security requirements specification derived from the risk assessment. Secure-by-design architecture description. Verification evidence for security controls (penetration testing, vulnerability scanning, fuzzing where applicable to the UI and API surfaces). 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. Minimum IT requirements communicated to the user per Annex I Section 17.4 — operating system versions, network configuration, authentication requirements, what the user must do to keep their own environment safe. For a SaMD the cybersecurity evidence ends up being one of the heaviest sections of Annex II Section 6 because there is no mechanical or biological evidence to compete with it for space. Auditors understand this and sample the cybersecurity artefacts accordingly. A SaMD with a thin cybersecurity file is a SaMD with a thin technical file. ## The version-control challenge This is the consideration that catches the most SaMD teams by surprise. A physical device has a design revision. It changes infrequently and every change triggers a formal process. A SaMD ships a new build every sprint — sometimes every day — and each build the user interacts with has to map back to a specific technical-file state. The regulatory question is simple. For the build a user is running right now, which version of the technical documentation describes that build? If the answer is "an older version of the file that has since been updated" or "we are not sure" or "the file describes the product in general," there is a problem. The technical file has to match what is shipped. The software configuration management discipline from EN 62304:2006+A1:2015 becomes the regulatory mechanism that makes this answer real. Every release has a release record. The release record names the version, the source-code state, the SOUP/SBOM snapshot, and the version of the technical documentation that covers it. When a new release goes out, either the technical file is already updated and linked, or the release does not go out. For small changes within the planned scope of the current filing, the existing technical file stays valid and the release record points to the current file version. For changes that alter the intended purpose, the classification, the risk profile, the security posture, or anything else the Notified Body certificate is conditioned on, the change triggers a significant-change assessment under MDR Article 120 and the applicable Notified Body process. The [MDR software lifecycle post](/blog/mdr-software-lifecycle-iec-62304) covers the lifecycle mechanics; the point here is that the version-control discipline is what makes the Annex II file true at any given moment. Teams that ship continuously handle this by treating the technical file itself as a versioned artefact tied to the software version. Teams that do not handle it end up with a file that describes a product that no longer exists in the form the file describes. The auditor finds this in about fifteen minutes by asking which version is shipped and comparing the released build to the version cited in the file's cover page. ## Common mistakes - **Treating the software's marketing name as the "device."** The device is a specific software version with a specific set of functions and a specific intended purpose. Not a product family. - **Screenshot-based labelling.** Section 2 contains screenshots rather than document-controlled source for the label and IFU text that runs in the UI. - **Cybersecurity as a one-time pen test.** A report from months ago, no SBOM, no ongoing vulnerability monitoring, no disclosure process. For a SaMD this is an immediate finding. - **Release record missing.** The team ships from main continuously but cannot produce a documented release decision for the version a user is running right now. - **Technical file not versioned with the software.** The file exists, but no one can say which release it describes. Any release. The cover page has a date and no version. - **Software safety classification applied to the whole product in bulk.** Either bulk Class C "to be safe" with no reasoning at the software-item level, or bulk Class A without a hazard analysis. Neither survives review. - **Clinical evaluation written to a product description, not to a release.** The clinical claims are evaluated against a version of the software that has since drifted. ## The Subtract to Ship angle SaMD invites parallel documentation stacks. The engineering team has requirements in one tool, architecture in another, CI evidence in a third, release notes in a fourth. The regulatory team produces a separate set of documents that duplicates the engineering work in "regulatory shape." The file grows. The synchronisation breaks. The audit finds drift. The Subtract to Ship discipline for a SaMD technical file is the same discipline it is everywhere else in the [Subtract to Ship framework for MDR](/blog/subtract-to-ship-framework-mdr). Every artefact has to trace to a specific Annex II section or a specific clause of EN 62304:2006+A1:2015, EN IEC 81001-5-1:2022, or EN ISO 14971:2019+A11:2021. Artefacts that do not trace come out. The engineering team's existing artefacts become the source of truth, filtered into Annex II shape rather than duplicated in parallel. The [SaMD compliance checklist for startups](/blog/mdr-software-compliance-checklist-startups) is the operational checklist the subtraction runs against. A subtracted SaMD file is small enough to update on every release and honest enough to match what actually ships. ## Reality Check — Where do you stand? 1. Does your Annex II Section 1 name the specific software release version the file currently describes, or does it describe the product in general terms? 2. Is the label and IFU text rendered by your UI under document control at the source level, with a traceable link to the release build? 3. Do you have a security risk assessment, security requirements, SBOM, vulnerability monitoring, and disclosure process under EN IEC 81001-5-1:2022, filed inside Annex II? 4. For the build your users are running right now, can you produce the release record, the source-code state, the SOUP/SBOM snapshot, and the version of the technical file that covers it? 5. Does every release go through a significant-change assessment decision before it ships? 6. Is the clinical evaluation report written against the current released version, or against a product description that has since drifted? 7. Is your software safety classification assigned at the software-item level under EN 62304:2006+A1:2015 with reasoning tied to the EN ISO 14971:2019+A11:2021 risk file? 8. Are the minimum IT requirements you communicate to users under Annex I Section 17.4 documented, shipped with the software, and matched by what the user actually needs to run the product safely? ## Frequently Asked Questions **Does a SaMD need the same Annex II sections as a physical device?** Yes. MDR Annex II is device-agnostic. Every section applies. What changes is the shape of the content that fills each section. Section 1 describes software functions and release versions rather than physical dimensions. Section 2 describes labelling rendered in the UI rather than printed on a box. Non-applicable items (sterility, biocompatibility, electrical mains safety) are marked non-applicable with reasoning, the same way any other file handles items outside its scope. **Where do the rendered labels and in-app IFU text live in the technical file?** In Annex II Section 2, as document-controlled source text under EN ISO 13485:2016+A11:2021, with a traceable link from the text in the file to the release build of the software that renders it. Screenshots alone are not sufficient because they cannot be maintained against a live UI. The text source is the controlled artefact; the screenshot is an illustration. **How often do I need to update the technical file if I ship weekly releases?** The file has to be true for the version that is shipped. For releases that stay within the planned scope of the current filing, the existing file remains valid and the release record references it. For releases that change the intended purpose, classification, risk profile, or security posture, the file is updated and a significant-change assessment is triggered before the release goes out. Continuous shipping is compatible with MDR compliance; undocumented continuous shipping is not. **Does MDCG 2019-11 Rev.1 change the technical documentation requirements for SaMD?** MDCG 2019-11 Rev.1 (June 2025) is guidance on qualification and classification of software under the MDR and IVDR. It does not add new technical documentation requirements — those come from MDR Annex II and Annex I Section 17 directly — but it defines whether a piece of software is in scope as a medical device and how it is classified under Annex VIII Rule 11. If the Rev.1 update changes your qualification or classification answer, it changes the scope of the file the software has to sit inside. **Is cybersecurity documentation optional for a SaMD with no network connectivity?** No. Annex I Section 17.2 applies regardless of network topology. Even an offline SaMD handles software supply chain risk, authentication of updates, integrity of the installed package, and protection of patient data at rest. The cybersecurity lifecycle under EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1 applies in proportion to the risk, not as an all-or-nothing switch. **Can a SaMD technical file be maintained entirely from the engineering tools the team already uses?** In principle yes, and it is the right direction to aim at. The artefacts under document control have to satisfy EN ISO 13485:2016+A11:2021 and have to be accessible to the auditor in a form that resolves the GSPR cross-references. If the engineering tools support that (controlled exports, versioned artefacts, auditor-accessible snapshots), the technical file becomes a live view into the engineering system rather than a parallel stack. If the engineering tools do not support that, the file ends up being a parallel stack that has to be reconciled manually — which is the failure mode Subtract to Ship is designed to prevent. ## Related reading - [Technical Documentation Under MDR](/blog/technical-documentation-under-mdr) — the Annex II pillar this post sits under. - [MDR Annex II Structure, Section by Section](/blog/mdr-annex-ii-structure) — the section walkthrough the SaMD file has to match. - [Software Documentation in the Technical File](/blog/software-documentation-technical-file) — the general software documentation mapping for any software-containing device. - [Labelling a Software as a Medical Device](/blog/labeling-software-medical-device) — the rendered-labelling mechanics for the Section 2 content. - [What Is Software as a Medical Device (SaMD)?](/blog/what-is-software-as-medical-device-samd-mdr) — the qualification step that scopes whether this file applies. - [MDR Software Lifecycle Requirements: How IEC 62304 Helps You Demonstrate Conformity](/blog/mdr-software-lifecycle-iec-62304) — the EN 62304:2006+A1:2015 lifecycle that produces most of the evidence. - [MDR Software Compliance Checklist for Startups](/blog/mdr-software-compliance-checklist-startups) — the operational checklist the SaMD file is subtracted against. - [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology applied to the SaMD technical file. ## Sources 1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex II (technical documentation), Annex I Section 17 (electronic programmable systems and software). 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. MDCG 2019-11 Rev.1 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR. October 2019; Revision 1, June 2025. --- *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. MDR Annex II and Annex I Section 17 are the binding source; EN 62304:2006+A1:2015 and MDCG 2019-11 Rev.1 are the harmonised and interpretive tools the SaMD file is built with. For startup-specific support on SaMD technical documentation, release-to-file traceability, and cybersecurity lifecycle implementation, Zechmeister Strategic Solutions is where this work is done in practice.* --- *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).*