What is EU MDR technical documentation for medical software?

EU MDR technical documentation (also called a technical file) is the complete body of evidence that demonstrates your SaMD meets EU MDR 2017/745 requirements. For medical software, it is structured according to Annex II of EU MDR and includes: device description and specifications, software architecture and IEC 62304 lifecycle documentation, GSPR compliance evidence, risk management file (ISO 14971), clinical evaluation report (CER), usability engineering file, cybersecurity documentation, and post-market surveillance plan. The technical file is reviewed by a Notified Body for Class IIa, IIb, and III devices.

What does EU MDR Annex II require for SaMD?

EU MDR Annex II technical documentation for SaMD must include: (1) Device description and specification including software version, intended purpose, and classification justification under Rule 11; (2) Information supplied by the manufacturer — labelling and IFU; (3) Design and manufacturing information including software architecture, IEC 62304 lifecycle documents, SOUP list, and algorithm descriptions; (4) General Safety and Performance Requirements checklist mapped to your software; (5) Benefit-risk analysis and risk management per ISO 14971; (6) Product verification and validation including IEC 62304 testing evidence; (7) Clinical evaluation report per MDCG 2020-1; (8) Post-market surveillance plan. For AI/ML software, Annex II must also address training data governance per EU AI Act Annex IV from August 2026.

How long does it take to create EU MDR technical documentation for SaMD?

For a SaMD company starting from scratch with no prior regulatory documentation, creating a complete EU MDR technical file typically takes 6 to 12 months. Companies with existing ISO 13485 QMS and IEC 62304 software lifecycle documentation can reduce this to 3 to 6 months. The clinical evaluation report is usually the longest single element — a well-structured CER for a Class IIa SaMD takes 4 to 8 weeks to write properly. The most common mistake is underestimating the clinical evidence requirements under MDCG 2020-1.

What is the difference between Annex II and Annex III in EU MDR?

Annex II defines the full technical documentation that all medical devices requiring CE marking must have. Annex III defines the post-market surveillance documentation specifically — the PMS plan, PSUR (Periodic Safety Update Report) for Class IIa and above, and SSCP (Summary of Safety and Clinical Performance) for Class IIb and III. For SaMD, Annex II is the main technical file; Annex III documents are created after CE mark and maintained throughout the device lifecycle.

What are the most common EU MDR technical documentation failures for SaMD?

The eight most common technical documentation gaps for SaMD identified in Notified Body audits are: (1) GSPR checklist not mapped to software-specific requirements; (2) Clinical evaluation report treating software like a hardware device rather than following MDCG 2020-1; (3) Risk management file not covering software-specific hazards under ISO 14971 Clause 4.3; (4) IEC 62304 safety class not formally documented and justified; (5) SOUP (Software of Unknown Provenance) list missing or incomplete; (6) Cybersecurity documentation absent or referencing MDCG 2019-16 without substantive evidence; (7) Usability engineering file (IEC 62366) missing summative evaluation; (8) Intended purpose statement too vague to support classification justification.

Do I need a Notified Body for EU MDR technical documentation?

Class I SaMD (devices that do not have a measuring function and are not sterile or reusable surgical instruments) can self-declare conformity — no Notified Body assessment of the technical file is required. Class IIa, IIb, and III SaMD require a Notified Body conformity assessment, which includes a full review of the technical file against Annex II requirements. The NB will issue a certificate only when the technical documentation is complete and demonstrates conformity with the General Safety and Performance Requirements.

EU MDR Technical Documentation for SaMD: Complete Annex II Requirements Guide 2026

1. What is EU MDR technical documentation?

EU MDR technical documentation — commonly called the technical file — is the complete body of evidence that demonstrates your medical device meets all applicable requirements of EU MDR 2017/745. It is not a single document but a structured collection of documents, test reports, analyses, and records that a Notified Body reviews before issuing a CE certificate.

The structure is defined by two Annexes of EU MDR:

Annex II — Technical documentation. The main technical file covering device description, design, verification, clinical evaluation, and post-market planning.
Annex III — Technical documentation on post-market surveillance. The PMS plan, PSUR, and SSCP maintained throughout the device lifecycle.

For SaMD, the technical file has the same mandatory structure as any medical device — but the content of each section looks fundamentally different from a hardware device. Most failures in NB audits happen because software companies populate hardware-oriented templates without understanding what software-specific evidence each section actually requires.

Which device classes need a technical file?

All CE-marked medical devices need an Annex II technical file. For Class I SaMD (without measuring function, not sterile), the manufacturer self-declares conformity — no NB reviews the file, but it must still exist and be available on request. Class IIa, IIb, and III SaMD have their technical file reviewed and approved by a Notified Body before CE mark is granted.

2. Annex II — complete section-by-section breakdown

Annex II of EU MDR 2017/745 contains six numbered sections. Here is what each requires, and what "complete" looks like for a SaMD:

Annex II section	What it requires for SaMD	Key standards
1. Device description & specification	Intended purpose, intended users, intended patient population, contraindications, device variants, software version(s), classification justification under Rule 11, UDI. For SaMD: exact algorithm description, input/output specification, hardware dependencies.	MDCG 2019-11
2. Information supplied by manufacturer	All labelling (including software version labelling), Instructions for Use. For SaMD: IFU must specify minimum hardware/OS requirements, describe what AI/ML outputs mean and their limitations, include cyber hygiene instructions if applicable.	Annex I §23
3. Design & manufacturing information	For SaMD: software architecture description, development environment, programming languages, IEC 62304 software safety class justification, SOUP list with version and risk assessment, change management procedures, build and release process.	IEC 62304
4. GSPR — General Safety & Performance Requirements	A checklist mapping every applicable GSPR from Annex I of EU MDR to the specific evidence in your technical file. For SaMD: must address §17 (electronic programmable systems), §18 (software), and §23 (IFU). Each requirement must be marked as applicable, not applicable (with justification), or complied with via specific document references.	Annex I
5. Benefit-risk analysis & risk management	Complete risk management file per ISO 14971:2019, covering the full lifecycle. For SaMD: must include software-specific hazards (algorithmic errors, incorrect outputs, cybersecurity threats, usability failures). Risk management must address residual risks and demonstrate overall benefit-risk acceptability.	ISO 14971:2019
6. Product verification & validation	Results of all V&V activities: software testing reports (unit, integration, system, regression), usability engineering file with summative evaluation per IEC 62366-1, cybersecurity testing per MDCG 2019-16, clinical evaluation report, and — for AI/ML — algorithm validation across the intended patient population.	IEC 62304, IEC 62366

The section NBs scrutinise most

Section 4 (GSPR checklist) and Section 6 (V&V, specifically the CER) are where the majority of SaMD technical file rejections originate. A superficial GSPR checklist with vague references and a CER that treats software like a hardware device will fail regardless of how good the actual software is.

3. SaMD-specific requirements not in hardware files

The following documentation areas are either absent from hardware device templates or substantially more demanding for SaMD. If you are adapting an off-the-shelf technical file template, these sections need to be built from scratch:

Software architecture documentation

A description of the software's architecture is required under Section 3 and referenced throughout the technical file. For SaMD this means: architecture diagrams showing major components and their interfaces, data flow documentation, description of external systems the software communicates with, and identification of software items that contribute to safety. The architecture description is the backbone that the GSPR checklist, risk management, and V&V results all reference.

IEC 62304 software lifecycle documentation

EU MDR does not directly reference IEC 62304 — but Annex I §17 requires that software be developed using a state-of-the-art software development lifecycle, and IEC 62304 is the internationally recognised standard for this. Your NB will expect it. The IEC 62304 documentation set includes: software development plan, software requirements specification, software architecture design, unit implementation and verification records, software integration testing records, and software system testing records. The class (A, B, or C) you assign to your software determines which of these are mandatory.

SOUP list (Software of Unknown Provenance)

Every open-source library, third-party component, operating system, database, and framework your software depends on must be listed with version number, published known anomalies, and risk assessment. A missing or incomplete SOUP list is one of the most common NB findings. If your software uses React, PostgreSQL, TensorFlow, or any other open-source dependency — it belongs in the SOUP list.

Cybersecurity documentation

MDCG 2019-16 defines the cybersecurity requirements for EU MDR medical devices. For SaMD, this means a dedicated security section covering: threat modelling, security risk assessment, secure development practices, penetration testing or vulnerability assessment, and post-market security monitoring plan. NBs are increasingly scrutinising cybersecurity documentation — a one-page reference to "following best practices" no longer passes review.

Usability engineering file

IEC 62366-1 usability engineering is required for all SaMD. The file must include: intended use context analysis, identification of use-related hazards, formative evaluation evidence (user testing during development), and summative evaluation (final formal validation with representative users). The summative evaluation must demonstrate that use errors identified in the risk assessment are adequately mitigated. This is the section most commonly absent or incomplete in SaMD technical files.

Clinical evaluation report for SaMD

The CER is the most challenging and most commonly failed section. For SaMD, the CER must follow MDCG 2020-1 guidance, which defines a specific methodology for software: literature review on the clinical condition, state of the art for comparable software, clinical data on your specific software (clinical investigation results or real-world performance data), and clinical performance assessment. A CER that treats your software like a hardware implant — citing material biocompatibility studies, for example — will be rejected immediately.

Not sure what's missing in your technical file? A structured gap analysis identifies exactly which sections are incomplete before your Notified Body does.

See documentation audit →

4. Annex III — post-market documentation

Annex III covers the post-market surveillance documentation that must be in place before CE mark is granted and maintained throughout the device lifecycle. For SaMD, three documents are required:

PMS plan (all classes)

The Post-Market Surveillance plan defines how you will proactively collect and analyse real-world data on your device's safety and performance after market placement. For SaMD this must include: monitoring of bug reports and user-reported issues, tracking of software updates and their effect on clinical performance, monitoring of relevant scientific literature, and — for AI/ML software — continuous monitoring of algorithm performance metrics including accuracy drift and subgroup performance. The PMS plan must be specific and measurable; generic statements about "monitoring user feedback" do not satisfy the requirement.

PSUR (Class IIa, IIb, III)

The Periodic Safety Update Report is a periodic analysis of the data collected under the PMS plan. For Class IIa SaMD, it must be updated at minimum every two years. For Class IIb and III, annually. The PSUR must reach a documented conclusion about whether the benefit-risk balance remains acceptable and whether any corrective action is needed.

SSCP (Class IIb and III)

The Summary of Safety and Clinical Performance is a public document, validated by the Notified Body and published in EUDAMED. It must summarise the clinical evaluation, intended purpose, residual risks, and post-market performance data in language accessible to non-specialists. For Class IIb and III SaMD, SSCP publication in EUDAMED is mandatory — and EUDAMED becomes mandatory for all relevant modules from 28 May 2026.

5. The 8 gaps that fail SaMD technical files at NB audit

Based on technical file reviews and NB audit feedback across multiple SaMD certification projects, these are the most common reasons a technical file fails or requires major revision:

Gap 1

GSPR checklist not mapped to software

Generic hardware-oriented GSPR checklist with §17 and §18 (software-specific requirements) left blank, marked N/A without justification, or referenced vaguely to "the IFU".

Gap 2

CER written for hardware, not SaMD

Clinical evaluation not following MDCG 2020-1 methodology. No clinical performance data specific to the software. Literature review covering the clinical condition but not the algorithm's performance.

Gap 3

IEC 62304 safety class not justified

Software safety class (A, B, or C) stated without a formal documented justification. Or Class A assigned to software that clearly contributes to hazardous situations — a finding NBs flag immediately.

Gap 4

SOUP list missing or outdated

No SOUP list, or a list that was created at development start and never updated. Version numbers missing. No known anomalies review. No risk assessment per component.

Gap 5

Cybersecurity section absent

No dedicated cybersecurity documentation. MDCG 2019-16 mentioned by name in the GSPR but no threat model, no security testing evidence, no post-market security monitoring plan.

Gap 6

Usability — no summative evaluation

IEC 62366 referenced but only formative (iterative design) evaluation documented. Final summative evaluation with representative users — the one that actually validates risk mitigations — missing entirely.

Gap 7

Risk management — software hazards missed

ISO 14971 risk file covers hardware-type hazards but misses software-specific ones: algorithmic errors producing incorrect outputs, failure modes due to network connectivity loss, incorrect user interpretation of AI recommendations.

Gap 8

Intended purpose too vague for Rule 11

Intended purpose statement does not support the classification justification. "Assists clinicians in decision-making" is not a compliant intended purpose — it needs to specify the clinical condition, the output, and the intended user population precisely.

6. Technical documentation checklist for SaMD

Use this checklist to assess the completeness of your technical file before submitting to a Notified Body. Every item must be present, current, and cross-referenced.

Annex II — core sections

Device description — intended purpose, intended users, contraindications, software version(s), UDI, Rule 11 classification justification with documented rationale
Labelling & IFU — compliant with Annex I §23, version-controlled, includes minimum system requirements, AI/ML output limitations where applicable
Software architecture — architecture diagram, component descriptions, external interfaces, data flows, identification of safety-critical software items
IEC 62304 documentation set — development plan, SRS, architecture design, unit/integration/system test records, safety class justification
SOUP list — all third-party components with version, licence, known anomalies review, risk assessment per component
GSPR checklist — all Annex I requirements assessed (applicable / not applicable with justification / complied with via specific document reference), §17 and §18 fully addressed
ISO 14971:2019 risk management file — risk management plan, hazard identification, risk estimation, risk evaluation, risk controls, residual risk assessment, benefit-risk conclusion, includes software-specific hazards
Cybersecurity documentation — threat model, security risk assessment, secure development evidence, penetration testing / vulnerability assessment results, post-market security monitoring plan (MDCG 2019-16)
Usability engineering file — use context analysis, use-related hazard identification, formative evaluation records, summative evaluation protocol and results (IEC 62366-1)
Clinical evaluation report — MDCG 2020-1 methodology, literature review, clinical performance data for the specific software, clinical performance assessment, PMCF plan

Annex III — post-market documentation

PMS plan — proactive data collection methods, complaint handling procedure, vigilance reporting procedure, AI/ML performance monitoring metrics where applicable
PSUR — required for Class IIa+ before CE mark; update schedule defined (2-yearly for IIa, annually for IIb/III)
SSCP — required for Class IIb and III; NB-validated; registered in EUDAMED

SaMD-specific additions (AI/ML software)

Algorithm description — model architecture, training methodology, performance metrics on validation dataset, subgroup performance analysis
Training data governance — dataset description, inclusion/exclusion criteria, demographic representativeness, bias assessment (required from August 2026 under EU AI Act)
Change management procedure — defines when a software change or model update constitutes a significant change requiring NB notification or new conformity assessment

7. How long does it take — realistic timelines

Timeline depends heavily on what documentation already exists. Here are realistic estimates based on actual SaMD certification projects:

Starting point	Time to complete Annex II technical file	Main bottleneck
No prior regulatory documentation	9–14 months	IEC 62304 documentation, CER clinical evidence
ISO 13485 QMS in place, no technical file	6–10 months	CER, usability summative evaluation
Prior MDD technical file, transitioning to MDR	4–8 months	CER rebuild, GSPR mapping, cybersecurity gap
Existing MDR file with specific gaps	6–12 weeks per gap	Depends on gap type — CER is always longest

The CER is always the critical path

The Clinical Evaluation Report is the single longest element to produce and the most commonly rejected. For Class IIa SaMD with existing real-world performance data, a compliant CER takes 4–8 weeks. For Class IIb software seeking clinical investigation data, plan 6–12 months for the evidence generation alone. Start the CER first, in parallel with everything else.

The fastest path to a complete technical file is a structured gap analysis at the start — before any writing begins. A technical documentation audit identifies exactly which sections exist, which need to be created from scratch, and which existing documents need to be updated. This prevents the most expensive mistake in SaMD certification: spending months writing documentation only to discover it doesn't meet NB requirements at submission.

For teams building their ISO 13485 QMS in parallel with the technical file — which is the typical path for software startups — coordinating QMS procedures with technical file requirements reduces total timeline by 2–3 months. The SOUP management procedure, change management procedure, and risk management procedure in your QMS generate outputs that go directly into the technical file.

EU MDR technical documentation for medical software: the complete Annex II requirements guide