Resource

    MDR technical documentation: Annex II and Annex III

    Technical documentation under the MDR is often described as a device file, but that phrase can be misleading if it suggests one static binder. In reality, Annex II and Annex III define a connected set of information that should explain the device clearly, justify compliance, and stay current as the device evolves.

    What Annex II covers

    Annex II is the core structure for MDR technical documentation. It starts with device description and specification, including intended purpose, variants, accessories, principles of operation, and the information needed to identify the product clearly. This opening section matters more than many teams realise, because everything else in the file depends on it. If the device description is unclear, the rest of the file becomes harder to defend.

    Annex II also expects information on classification rationale, design and manufacturing, and the General Safety and Performance Requirements, often documented through a GSPR checklist or matrix. Beyond that, manufacturers need verification and validation evidence, benefit-risk information, and the outputs that show the device performs as intended and remains acceptably safe.

    In other words, Annex II is not just evidence storage. It is the logic of the device translated into regulatory form: what the device is, why it falls under a given class, how it was built, how safety and performance were demonstrated, and how the manufacturer knows the claims are justified.

    The main Annex II building blocks

    Most manufacturers organise Annex II around several recurring modules. Device description and specification usually includes intended use, indications, contraindications, product variants, and essential design features. Classification rationale explains which Annex VIII rules apply and why the resulting class is appropriate. Design and manufacturing information then describes how the product is developed and controlled.

    The GSPR section maps the relevant requirements of the MDR to the evidence that demonstrates conformity. This can involve standards, test reports, risk controls, biological evaluations, software validation, usability evidence, and other technical outputs. Benefit-risk work and clinical evaluation then explain why the device’s expected benefits outweigh residual risks and how the clinical evidence supports the intended purpose.

    Finally, Annex II includes labelling, IFU, and other materials presented to users, because those materials are part of the device’s safe and effective use. Reviewers often move back and forth between these sections, which is why alignment matters so much.

    • Device description and specification
    • Classification rationale
    • Design and manufacturing information
    • GSPR conformity evidence
    • Benefit-risk documentation and clinical evaluation
    • Labelling, IFU, and validation outputs

    What Annex III adds: post-market surveillance documentation

    Annex III complements Annex II by focusing on post-market surveillance documentation. It includes the PMS Plan and the procedures manufacturers use to collect, record, and assess relevant post-market data. The point is to show not only that the device was supported at launch, but that the manufacturer has a structured way to keep learning from real-world use.

    This includes how complaints, vigilance data, literature, trend information, and other post-market sources are reviewed. It also includes how that information feeds back into risk management, clinical evaluation, and where necessary PMCF or corrective actions. For higher-risk devices, PSUR obligations sit alongside this framework as part of the ongoing reporting model.

    Annex III therefore turns the device file into a lifecycle system. Pre-market justification and post-market learning are meant to connect. If they do not, the technical documentation may look complete on paper but still fail to show effective control over the device in the field.

    Why internal consistency is so important

    One of the hardest parts of MDR technical documentation is not producing each section individually. It is keeping all sections internally consistent. Intended purpose in the device description should match claims in the IFU, align with the classification rationale, and be supported by the CER. Risk controls in the risk file should appear consistently in design documentation, verification evidence, and user-facing materials. PMS findings should influence CER and benefit-risk conclusions where relevant.

    When documentation is fragmented, inconsistencies appear quickly. A claim updated in marketing language may not make its way into the CER. A design change may affect testing assumptions without being reflected in the GSPR matrix. A PMS signal may call for risk re-evaluation, but the files remain disconnected. During audits or Notified Body reviews, these gaps are often more damaging than the absence of a single document because they suggest the system is not truly under control.

    Strong technical documentation is therefore less about volume and more about traceability between related sections. Reviewers should be able to follow the logic of the device from intended purpose to evidence to post-market learning without finding contradictions.

    How manufacturers can make Annex II and III manageable

    The most effective teams structure technical documentation around reusable source data rather than isolated document drafts. They define key product facts once, make ownership clear, and create controlled links between classification, GSPR evidence, risk management, CER content, PMS outputs, and user-facing materials. This makes updates more predictable and reduces the chance of silent inconsistencies.

    For SMEs especially, this structured approach is often the difference between a maintainable file and a permanent remediation project. Every change to intended purpose, variant scope, evidence, or post-market findings should trigger a visible review path. If the organisation cannot see which sections are affected, it will end up rediscovering dependencies during each audit cycle.

    Annex II and III are demanding, but they are easier to handle when treated as one connected system rather than a collection of separate reports.

    Artifakt structures your device file around Annex II and III - so every section draws from the same source. Talk to us.

    Talk to us