Template reference
Which documents do you actually need?
MDR compliance requires two separate documentation efforts. The first is a company-wide quality and regulatory system. The second is a per-product technical file. The tables below show exactly which templates apply to each company role and each product profile, so you can skip the guesswork and focus on the documents that matter for your situation.
How to read the tables
You will need this document. Start it early and keep it maintained.
Needed only when a specific condition applies (described in the notes).
This document does not apply to the given role or product type.
Part one
Company-level templates by role
Your MDR role determines which company-wide procedures you must establish. Manufacturers carry the heaviest burden. Importers and authorized representatives need a focused subset. Companies holding multiple roles combine the obligations of each.
| Template | Category | Legal manufacturer | Virtual manufacturer | Authorized representative | Importer / distributor | Multiple roles |
|---|---|---|---|---|---|---|
| Quality Manual, Policy & Objectives | QMS core | Required | Required | N/A | N/A | Required |
| SOP Document & Record Control | QMS core | Required | Required | N/A | N/A | Required |
| SOP Human Resources Administration | QMS core | Required | Required | N/A | N/A | Required |
| List of Training Documentation | QMS core | Required | Required | N/A | N/A | Required |
| ISO 13485:2016 Mapping of Requirements to Documents | QMS core | Required | Required | N/A | N/A | Required |
| Document List QMS | QMS core | Required | Required | Required | N/A | Required |
| Appointment as Person Responsible for Regulatory Compliance | QMS core | Required | Required | N/A | N/A | Required |
| Training Record | QMS core | Required | Required | N/A | N/A | Required |
| List of Regulatory Requirements | QMS core | Required | Required | N/A | N/A | Required |
| SOP PurchasingRequired when critical processes are outsourced | Supplier control | Conditional | Conditional | N/A | N/A | Conditional |
| List of Qualified SuppliersRequired when critical processes are outsourced | Supplier control | Conditional | Conditional | N/A | N/A | Conditional |
| Supplier ChecklistRequired when critical processes are outsourced | Supplier control | Conditional | Conditional | N/A | N/A | Conditional |
| SOP Corrective and Preventive Action (CAPA) | QMS operations | Required | Required | N/A | N/A | Required |
| Audit Program | QMS operations | Required | Required | N/A | N/A | Required |
| Management Review Report | QMS operations | Required | Required | N/A | N/A | Required |
| List of CAPAs | QMS operations | Required | Required | N/A | N/A | Required |
| Audit Plan | QMS operations | Required | Required | N/A | N/A | Required |
| Audit Report | QMS operations | Required | Required | N/A | N/A | Required |
| SOP Internal Audit | QMS operations | Required | Required | N/A | N/A | Required |
| SOP Management Review | QMS operations | Required | Required | N/A | N/A | Required |
| SOP Product Certification and Registration | QMS operations | Required | Required | N/A | N/A | Required |
| SOP SalesConditional — needed when the company has direct sales channels | QMS operations | Conditional | Conditional | N/A | N/A | Conditional |
| SOP Update of Regulations | QMS operations | Required | Required | N/A | N/A | Required |
| SOP Feedback Management and Customer Complaints | Post-market system | Required | Required | Required | Required | Required |
| SOP VigilanceConditional for standalone importers — depends on escalation responsibilities | Post-market system | Required | Required | Required | Conditional | Required |
| SOP Post-Market Surveillance | Post-market system | Required | Required | N/A | N/A | Required |
| SOP Clinical Evaluation | Clinical evaluation | Required | Required | N/A | N/A | Required |
| Software ListRequired when the company uses validated software tools | Software validation | Conditional | Conditional | N/A | N/A | Conditional |
| Software Validation FormRequired when the company uses validated software tools | Software validation | Conditional | Conditional | N/A | N/A | Conditional |
| SOP Software ValidationRequired when the company uses validated software tools | Software validation | Conditional | Conditional | N/A | N/A | Conditional |
| SOP Integrated Software DevelopmentRequired when products include software | Software lifecycle | Conditional | Conditional | N/A | N/A | Conditional |
| SOP Change ManagementRequired when products include software | Software lifecycle | Conditional | Conditional | N/A | N/A | Conditional |
| SOP DeploymentRequired when products include software | Software lifecycle | Conditional | Conditional | N/A | N/A | Conditional |
| SOP Software Problem ResolutionRequired when products include software | Software lifecycle | Conditional | Conditional | N/A | N/A | Conditional |
| SOP Machine Learning Model DevelopmentRequired when products include machine learning | Software lifecycle | Conditional | Conditional | N/A | N/A | Conditional |
| List of Medical Devices | Device registration | Required | Required | N/A | N/A | Required |
| Data Protection StatementConditional — needed when processing personal data | Data protection | Conditional | Conditional | Conditional | Conditional | Conditional |
| Data Protection and Confidentiality AgreementConditional — needed when processing personal data | Data protection | Conditional | Conditional | Conditional | Conditional | Conditional |
| List of Data Processing ActivitiesConditional — needed when processing personal data | Data protection | Conditional | Conditional | Conditional | Conditional | Conditional |
| Technical and Organizational MeasuresConditional — needed when processing personal data | Data protection | Conditional | Conditional | Conditional | Conditional | Conditional |
| ISO 27001:2023 Mapping of Requirements to DocumentsConditional — needed for ISO 27001 implementation | Information security | Conditional | Conditional | Conditional | Conditional | Conditional |
| Information Security ControlsConditional — needed for ISO 27001 implementation | Information security | Conditional | Conditional | Conditional | Conditional | Conditional |
| Information Security Policy and ScopeConditional — needed for ISO 27001 implementation | Information security | Conditional | Conditional | Conditional | Conditional | Conditional |
| SOP Information Security Risk AssessmentConditional — needed for ISO 27001 implementation | Information security | Conditional | Conditional | Conditional | Conditional | Conditional |
Legal manufacturer
Carries the full MDR obligation. All QMS core, CAPA, audit, management review, complaint, and vigilance procedures are required. The purchasing SOP and qualified supplier list become required as soon as any critical process is outsourced (design, software, sterilization, manufacturing, or testing).
Virtual manufacturer
Identical template obligations to a legal manufacturer. The same outsourcing condition applies to purchasing and supplier documents, but in practice virtual manufacturers nearly always outsource critical processes, making these documents effectively required.
Authorized representative
The authorised representative does not maintain the manufacturer's QMS but must track documentation on file, handle complaint forwarding, and escalate incidents. Document list, feedback management, and vigilance SOP are required. Data protection and information security templates remain conditionally applicable.
Importer / distributor
Needs traceability and verification controls. Feedback management (complaint intake and escalation to the manufacturer) is required. Vigilance SOP is conditional — it becomes required when the company is contractually responsible for escalating serious incidents.
Multiple roles
When a company holds more than one role (for example, manufacturer plus importer, or manufacturer plus authorized representative), it inherits the full manufacturer template set. Because the "multiple roles" path is treated as manufacturer-like, it receives all manufacturer-required templates. It also inherits the authorized representative's operational obligations (mandate, document availability) and the importer's escalation obligations — but these do not add additional templates beyond what the manufacturer route already requires.
Software capability
When the company develops or maintains software medical devices, an additional set of company-level SOPs and processes becomes required: integrated software development, change management, deployment, problem resolution, and QMS software validation. These templates appear as conditional for all manufacturer-like roles and become required once software capability is confirmed in the company intake.
Data protection & information security
Data protection (GDPR) and information security (ISO 27001) templates are shown as conditional for all company roles. They become increasingly important for companies that process personal health data, operate digital services, or develop connected or cloud-based medical devices. While not strictly MDR requirements, they are frequently expected by notified bodies and auditors.
Machine learning / AI software
Software medical devices can indicate that they use machine learning or AI algorithms. When the ML/AI question is answered "Yes," three algorithm-related templates are promoted from conditional to required: Algorithm Validation Report, Instructions on Data Acquisition, and Instructions on Data Annotation. These templates address the additional validation, data quality, and documentation expectations for ML-based medical devices under MDR.
Part two
Product-level templates by device profile
Every MDR medical device needs a baseline technical file. Additional templates are triggered by the device characteristics: software content, lay/home use, risk class, and implantable status. Products that fall outside the MDR route (IVD or other) receive no template recommendations — see the IVD/IVDR section below.
Baseline — every MDR medical device
These 15 templates are required or conditionally required for all MDR product types: non-active device, active device, software medical device, and implantable or high-impact device. They form the core technical file regardless of risk class.
| Template | Category | Status | Purpose |
|---|---|---|---|
| Intended Use | Core technical file | Required | Defines what the device does, for whom, and under which conditions. |
| MDR Classification Document | Core technical file | Required | Documents the classification rule, rationale, and resulting device class. |
| Checklist General Safety and Performance Requirements (GSPR) | Core technical file | Required | Maps general safety and performance requirements to evidence in the file. |
| Risk Management Plan | Risk management | Required | Defines the risk management scope, policy, criteria, and responsibilities. |
| Risk Management Report | Risk management | Required | Summarizes residual risk, benefit-risk conclusion, and release recommendation. |
| Clinical Evaluation Plan | Clinical evidence | Required | Sets the clinical questions, data sources, and evaluation method. |
| Clinical Evaluation Report | Clinical evidence | Required | Consolidates clinical evidence into a formal safety and performance conclusion. |
| Post-Market Surveillance Plan | Post-market | Required | Defines how post-market data will be collected, analyzed, and fed back into the file. |
| Instructions for Use (User Manual) | Core technical file | Required | Mandatory labeling and user documentation under MDR. |
| EU Declaration of Conformity | Core technical file | Required | Formal declaration required before placing the device on the EU market. |
| Checklist Clinical Evaluation Report | Clinical evidence | Required | Verifies completeness and consistency of the clinical evaluation. |
| Literature Evaluation Table | Clinical evidence | Required | Structured table for literature search, appraisal, and evidence mapping. |
| ISO 14971:2019 Mapping of Requirements to Documents | Risk management | Required | Maps ISO 14971 risk management requirements to product documentation. |
| Failure Mode and Effects Analysis (FMEA) Risk Table | Risk management | Required | The core risk analysis artifact with failure modes, causes, effects, and controls. |
| Document Roadmap TechDoc | Planning | Conditional | Useful for planning the order and ownership of technical documentation. |
Software add-on — devices with software impact
These 18 additional templates are required when the device is a standalone software medical device (SaMD), or when embedded software, firmware, or connected functionality affects clinical or safety performance. The software impact question is available for active devices, software devices, and implantable devices. It is not shown for non-active devices (which by definition have no active energy-driven or software-driven core function).
| Template | Category | Status | Purpose |
|---|---|---|---|
| Software Development and Maintenance Plan | Software lifecycle | Required | Covers requirements, architecture, implementation, verification, release, and change control. |
| Software Requirements List | Software lifecycle | Required | Explicit, traceable software requirements linked to risk controls and verification. |
| Software System Test Plan | Software lifecycle | Required | Formal verification and validation plan before software release. |
| IEC 62304:2006 Mapping of Requirements to Documents | Software lifecycle | Required | Maps IEC 62304 requirements to the software documentation set. |
| Software Architecture Description | Software lifecycle | Required | Documents the overall software architecture, items, and safety considerations. |
| Software Architecture Checklist | Software lifecycle | Required | Ensures the software architecture review is complete. |
| SOUP List (Software of Unknown Provenance) | Software lifecycle | Required | Documents all third-party software components with risk assessment. |
| User Needs List | Software lifecycle | Required | Top-level design input listing user needs and stakeholder requirements. |
| Checklist Software Release | Software lifecycle | Required | Formal completeness check before each software release. |
| Checklist Software Requirements Review | Software lifecycle | Required | Formal review checklist for software requirements completeness. |
| Checklist User Needs Review | Software lifecycle | Required | Formal review checklist for user needs completeness and consistency. |
| Change Evaluation List | Software lifecycle | Required | Documents software changes with regulatory impact evaluation. |
| Bug Fixes Documentation List | Software lifecycle | Required | Documents bug fixes with impact assessment and verification. |
| List of Known Anomalies | Software lifecycle | Required | Documents known software anomalies with risk assessment. |
| Questionnaire Cybersecurity for Medical Devices | Risk management | Required | Cybersecurity risk assessment for software medical devices. |
| Algorithm Validation ReportConditional — required for ML/AI devices | Software lifecycle | Conditional | Validation report for machine learning algorithms. |
| Instructions on Data AcquisitionConditional — required for ML/AI devices | Software lifecycle | Conditional | Defines data collection requirements for ML model development. |
| Instructions on Data AnnotationConditional — required for ML/AI devices | Software lifecycle | Conditional | Specifies data annotation procedures for ML model development. |
- Product type is "Software medical device" (always triggered)
- Software impact on clinical or safety performance is answered "Yes" (for active, implantable devices)
Not available for non-active devices. The software impact question is only shown for active devices, software devices, and implantable devices.
Usability add-on — lay users, home use, or software devices
These 5 additional templates are required when patients, caregivers, or non-professional users interact directly with the device. Also always triggered for software medical devices because of inherent user-interface considerations.
| Template | Category | Status | Purpose |
|---|---|---|---|
| Usability Evaluation Plan | Usability engineering | Required | Describes user profiles, critical tasks, use-error controls, and validation strategy. |
| Usability Evaluation Protocol | Usability engineering | Required | Controlled protocol for formative or summative usability testing. |
| Usability Evaluation Report | Usability engineering | Conditional | Created once usability testing has been executed and results are available. |
| IEC 62366-1:2015 Mapping of Requirements to Documents | Usability engineering | Required | Maps IEC 62366 usability engineering requirements to documentation. |
| List of Hazard-Related Use Scenarios | Usability engineering | Required | Identifies and documents hazard-related use scenarios for safety analysis. |
- Product type is "Software medical device" (always triggered)
- Home use or lay user interaction is answered "Yes" (for non-active, active, software, and implantable devices)
Professional-use-only hardware devices without software do not trigger this add-on, but human factors should still be addressed in the risk management file.
Higher-risk add-on — Class IIa, IIb, III, or implantable
Higher-class and higher-impact devices face stronger post-market obligations. These 5 templates are added on top of the baseline set.
| Template | Category | Status | Purpose |
|---|---|---|---|
| Periodic Safety Update Report (PSUR) | Post-market | Required | Periodic summary of post-market safety data, trends, and conclusions. |
| Post-Market Clinical Follow-Up Plan | Post-market | Required | Planned PMCF route or documented rationale for not conducting PMCF. |
| Post-Market Clinical Follow-Up Report | Post-market | Conditional | Created once PMCF activities have been performed and reviewed. |
| Field Safety NoticeConditional — template for when corrective actions are needed | Post-market | Conditional | Template for field safety notices when field safety corrective actions are required. |
| Incident Assessment FormConditional — template for assessing serious incidents | Post-market | Conditional | Template for assessing and documenting serious incidents and near-misses. |
- Risk class is IIa, IIb, or III
- Device is flagged as implantable or otherwise high-impact
For lower-risk devices that do not meet either trigger (Class I, Class I with qualifier, or "unsure" without implantable flag), the PSUR and PMCF Report are not applicable. However, the PMCF Plan remains Conditional — it is useful if the company needs to document the rationale for not conducting PMCF.
Combined view — all 43 product templates at a glance
This matrix shows every product template against seven representative device profiles. Each column assumes a typical configuration for that device type. See the footnotes below the table for assumptions and edge cases.
Column assumptions and notes
- Class I non-active (no home use)
- Simplest MDR route. No software impact question available for non-active devices. Usability is conditional on home/lay use. PMCF Plan is conditional (for documenting the rationale for not conducting PMCF). PSUR, PMCF Report are not applicable because the higher-risk trigger is not met.
- Class I with qualifier (sterile / measuring / reusable surgical)
- Same baseline template set as basic Class I. The qualifier (sterile, measuring function, or reusable surgical instrument) affects the conformity-assessment route and requires notified-body involvement for specific aspects. I-special now triggers the higher-risk add-on: PMCF Plan becomes required, and PSUR, PMCF Report, Field Safety Notice, and Incident Assessment Form become conditionally applicable.
- Class IIa active (no software)
- Higher-risk trigger is met (IIa). PSUR and PMCF Plan are required. Software templates are N/A because the column assumes no software impact. Usability is conditional on home/lay use.
- Class IIa active (with software)
- Same as above, plus all 18 software add-on templates become applicable because software impact is "Yes." Usability remains conditional on home/lay use (not automatically triggered by software impact on active devices — only by the "software medical device" product type or by the home use answer).
- Software medical device (any class)
- Software templates are always required (product type triggers them). Usability plan and protocol are always required (product type triggers them). The higher-risk post-market templates (PSUR, PMCF Plan as required, PMCF Report) depend on the risk class: a Class I SaMD would not trigger them, a Class IIa SaMD would. The column shows these as conditional to reflect this class dependency.
- Class III implantable (with software)
- Maximum template burden. All baseline, all higher-risk, and all software templates are required. Usability remains conditional on home use (implantable devices are often professional-use, but the answer may vary). The implantable flag independently triggers the higher-risk add-on even if the class were lower.
- IVD / other
- Outside the current MDR route. No MDR template recommendations are generated. See the IVD / IVDR section below for guidance on what applies instead.
Part three
Edge cases and special device characteristics
Several device characteristics are captured by the intake questions but do not directly change template recommendations. They influence the content, depth, and urgency of the templates rather than adding new ones.
Custom-made devices
When a device is manufactured specifically to a written prescription for an individual patient, the custom-made flag is set. This does not add or remove templates. However, the content of several templates changes significantly: the declarations, documentation emphasis, and conformity-assessment route need custom-made-specific tailoring. The core planning logic (intended use, risk, clinical evaluation) still applies, but some outputs and declarations differ from serial-production devices.
Sterile devices
The sterility question is asked for all MDR product types (non-active, active, software, implantable). A "Yes" answer does not trigger additional templates, but it changes the conformity-assessment expectations. Sterility-related validation and process controls become part of the route, and the GSPR checklist, risk management plan, and supplier control documents must address sterilization processes. For Class I sterile devices, the sterile qualifier may also require notified-body involvement for sterility aspects specifically.
Classification still uncertain
When the risk class is set to "unsure," no additional templates are added or removed. The same baseline set applies. However, the roadmap prioritizes resolving classification uncertainty before expanding the technical file, because the higher-risk add-on templates (PSUR, PMCF Plan, PMCF Report) depend on the final class determination. Until classification is resolved, the technical file may be incomplete.
Clinical investigation route
When the clinical evidence situation is set to "clinical investigation likely," no additional templates are triggered, but the roadmap moves clinical planning to the front. The Clinical Evaluation Plan and Report are already in the baseline set. The investigation route adds urgency and depth to those existing templates rather than introducing new ones.
Post-market lifecycle stage
When a product is already on the market, the roadmap shifts focus to post-market outputs: complaints, field experience, trends, and clinical updates should flow back into the risk and clinical conclusions. The same templates apply, but their content emphasis shifts from initial drafting to maintenance and updates.
Non-EU manufacturer
When the legal manufacturer is established outside the EU (or has a mixed structure), the company roadmap adds steps for setting up EU representation and agreements. This does not change company-level template recommendations — it adds operational and contractual obligations that are addressed through the mandate and document-availability controls rather than additional QMS templates.
Part four
IVD devices and the IVDR route
In vitro diagnostic medical devices (IVDs) fall under Regulation (EU) 2017/746 (IVDR), not MDR. MDR Training is optimized for MDR and does not generate IVDR-specific template recommendations. When a product is identified as "IVD or outside this MDR route," it receives no template recommendations and the system flags it as out of scope.
What happens when you select IVD
- No product templates are recommended
- The product is kept in the portfolio for planning visibility
- The system advises confirming whether the product belongs under IVDR or another regulatory framework
- MDR assumptions should not be reused for an IVD product without a separate IVDR analysis
Key differences between MDR and IVDR
While many company-level QMS concepts are shared (quality manual, document control, CAPA, audits, management review, vigilance), the product-level documentation differs significantly:
- Classification system: IVDR uses Rules 1-7 and risk classes A, B, C, D — not the MDR classification rules and classes I/IIa/IIb/III
- Performance evaluation: IVDR requires performance evaluation (scientific validity, analytical performance, clinical performance) instead of MDR clinical evaluation
- Common specifications: IVDR introduces common specifications for certain device groups, which do not exist under MDR
- Post-market: IVDR has its own PMPF (post-market performance follow-up) requirements distinct from MDR PMCF
- Notified body: IVDR significantly expanded the number of IVDs requiring notified-body involvement compared to the prior IVDD regime
- GSPR: IVDR has its own general safety and performance requirements (Annex I) that overlap with but differ from MDR Annex I
Company-level templates that still apply
If your company also holds MDR responsibilities (for example, you manufacture both MDR devices and IVDs), the company-level QMS templates from Part 1 still apply to the overall quality system. The company backbone is regulation-agnostic at the procedure level — the same quality manual, document control, CAPA, and audit processes typically serve both MDR and IVDR products. Product-level documentation, however, must follow the IVDR-specific route.