Technical Documentation for SaMD: What the File Actually Needs

The technical file for software is not the same as for hardware

If you come from a hardware background and try to adapt a hardware technical file template to software, you'll produce something that looks complete but misses what Notified Bodies actually need to see. Software technical documentation has a distinct shape: it's heavily focused on process evidence — documentation of how the software was developed, tested, and maintained — rather than physical specifications.

MDR Annex II and Annex III set the framework. But for software, the content of several Annex II sections is specified further by IEC 62304, the harmonised standard for software development lifecycle. These two have to work together in your file. Understanding how they map is the place to start.

What IEC 62304 requires and why it matters

IEC 62304 defines a lifecycle model for medical device software. The standard assigns each software system a safety classification (Class A, B, or C) based on the potential severity of harm from a software failure. This is related to but distinct from your MDR device class — the IEC 62304 classification drives the depth of documentation and testing required within the standard.

In practice, what IEC 62304 means for your technical file:

• Software development plan — your documented approach to development: methodology, tools, team roles, version control practices, change control processes. Notified Bodies look here to understand whether you have a controlled development environment.
• Software requirements specification — all functional and safety requirements, including requirements derived from your risk analysis. A common gap: software requirements that aren't traceable back to intended purpose and GSPR.
• Software architecture document — structural decomposition of the system into software items. For Class B and C, this needs to show how safety-critical components are identified.
• Detailed design documents — for Class C, this goes to the unit level.
• Verification and validation records — test plans, test cases, test results. The records need to show that you tested against the requirements you specified, not just that the software "works."
• Problem resolution records — how you handle bugs, anomalies, and defects found during development and post-market.

For Class A software (failure cannot contribute to harm), the requirements are lighter. For Class C (failure can cause death or serious injury), the documentation burden is significantly heavier.

The Annex II structure for a software technical file

Here's how a software technical file typically maps to Annex II:

Section 1 — Device description and specification: your software description including intended purpose, user interface overview, system architecture summary, hardware/software environment specifications (operating system, browser versions, dependencies), and a description of all software components.

Section 2 — Information supplied with the device: IFU, labelling, training materials. For software, IFU often covers version-specific limitations, minimum hardware specs, and cybersecurity user guidance.

Section 3 — Design and manufacturing information: for software this becomes your SDLC documentation — the IEC 62304 artefacts. This is the largest section for most SaMD files.

Section 4 — GSPR: your traceability matrix showing how each applicable General Safety and Performance Requirement is addressed. For software, GSPR 14–17 are the ones that take the most effort: IT security (17.2), interoperability, and electronic data.

Section 5 — Risk/benefit analysis: your ISO 14971 risk management file. For software, this includes software-specific hazards: algorithmic failures, incorrect outputs, connectivity risks, cybersecurity threats treated as hazards.

Section 6 — Product verification and validation: your V&V summary referencing the detailed records in Section 3.

Section 7 — Post-market data: your post-market surveillance plan, PMCF plan, and any data collected post-launch.

Section 8 — Clinical evaluation: your CER or equivalent. For software, this is the section most teams underestimate. See the clinical evaluation resource in this category for detail.

Version management — the part that trips people up most

Every software version that you release needs to be identifiable in the technical file. This doesn't mean a separate technical file for every version — it means your file must clearly state which version it applies to, and your change control process must document how each release was evaluated against your original requirements and risk file.

The rule of thumb: a change that introduces new functionality, changes the intended purpose, or affects safety-critical components requires documented change assessment and, potentially, re-qualification or new conformity assessment. Even a "minor" update that patches a bug in a safety-critical component needs to go through your change control process and be documented.

UDI plays into this too — software versions above certain thresholds trigger UDI updates. That's covered in the EUDAMED registration resource in this category.

What a Notified Body actually looks for

Teams are often surprised by what Notified Bodies spend the most time on in a SaMD file. It's usually not the architecture diagrams. It's traceability — can you show a thread from intended purpose, through requirements, through design, through testing, through risk controls, all the way to GSPR compliance? Gaps in that thread are where NB questions accumulate.

Build your file with traceability in mind from day one. A requirements management tool that links requirements to test cases and risk mitigations will pay for itself in review time saved.